:The NFS server problem I was referring to specifically came up in the case
:of the DTE work is as follows, and can't be solved through modifications
:to the name cache:
:
:- An NFS client uses lookups to retrieve the file handle of /foo/bar/baz
: on an NFS server. It sets the cwd of a proces
On Tue, 6 Sep 2005, Sergey Babkin wrote:
Corner cases and their handling *is* important. Find another way to do
whatever it is you're thinking you can do with "the real name of a
vnode".
This particular case is easy to handle: all that user 1 needs to do is
to do fstat() after opening the
On 2005-09-06 11:29, Sergey Babkin <[EMAIL PROTECTED]> wrote:
>Giorgos Keramidas <[EMAIL PROTECTED]>
>>On 2005-09-06 19:27, Igor Shmukler <[EMAIL PROTECTED]> wrote:
>>> Perhaps, I do not get it or maybe you are do not getting my point.
>>>
>>> There are times when resolving would not be possible or
>From: Giorgos Keramidas <[EMAIL PROTECTED]>
>On 2005-09-06 19:27, Igor Shmukler <[EMAIL PROTECTED]> wrote:
>> Perhaps, I do not get it or maybe you are do not getting my point.
>>
>> There are times when resolving would not be possible or a name returned is
>> not necessarily the one used when fi
On Tue, 6 Sep 2005, Matthew Dillon wrote:
NFS views from the client are one of those shades of gray, since
files and directories can be ripped up by other clients or the
server, but since clients have to assume a certain level of
consistency anyway it's hardly a show stopper from the
On 9/6/05, Robert Watson <[EMAIL PROTECTED]> wrote:
>
> On Tue, 6 Sep 2005, Kamal R. Prasad wrote:
>
> >> one or more names and none of these names are more correct or
> >> authoritative than any of the others. If a user does 'ln /bin/ls /tmp'
> >> (assuming /bin and /tmp are on the same filesys
At the cost of drawing ire from FreeBSD core developers, I will
point out that reverse-resolution is hardly a black-and-white issue.
There are many shades of grey, and there is a huge problem set that
can either be solved or 99.99% of the way solved (greatly reducing the
time r
On Tue, 6 Sep 2005, Kamal R. Prasad wrote:
one or more names and none of these names are more correct or
authoritative than any of the others. If a user does 'ln /bin/ls /tmp'
(assuming /bin and /tmp are on the same filesystem), it may be obvious
to you that /bin/ls is the "real name" is /tmp
>
> [snip]
I did. You just don't get it. A file may be associated with zero,
> one or more names and none of these names are more correct or
> authoritative than any of the others. If a user does 'ln /bin/ls
> /tmp' (assuming /bin and /tmp are on the same filesystem), it may be
> obvious to yo
On 2005-09-06 19:27, Igor Shmukler <[EMAIL PROTECTED]> wrote:
> Perhaps, I do not get it or maybe you are do not getting my point.
>
> There are times when resolving would not be possible or a name returned is
> not necessarily the one used when file was first accessed. We have discussed
> it here
Igor Shmukler <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> > Igor Shmukler <[EMAIL PROTECTED]> writes:
> > > You are correct about the Unix file system organization, but does it
> > > mean reliable vnode to fullname conversation is not possible?
> > Yes. Get over
Igor Shmukler <[EMAIL PROTECTED]> writes:
> You are correct about the Unix file system organization, but does it
> mean reliable vnode to fullname conversation is not possible?
Yes. Get over it.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
free
On Mon, 5 Sep 2005, Sergey Uvarov wrote:
all knows that vn_fullpath() is unreliable. However I really need to get
a filename for a given vnode. To simplify the task, I do not care of
synthetic file systems or hardlinks.
I have looked through archives in hope to find a better solution. It
see
13 matches
Mail list logo
