: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
o we may simply be screwed here :-).
Robert N M Watson
Thank you in advance,
Igor
-Original Message-
From: Robert Watson <[EMAIL PROTECTED]>
To: Igor Shmukler <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 16:21:47 +0100 (BST)
Subject: Re[2]: vn_fullpath() again
On Tue, 6 S
>
> [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
Watson <[EMAIL PROTECTED]>
To: Igor Shmukler <[EMAIL PROTECTED]>
Date: Tue, 6 Sep 2005 16:21:47 +0100 (BST)
Subject: Re[2]: vn_fullpath() again
>
> On Tue, 6 Sep 2005, Igor Shmukler wrote:
>
> >>> You are correct about the Unix file system organization, but doe
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
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 and everyone agreed on that. The hardlinks or files unlinked while vn
On Tue, 6 Sep 2005, Igor Shmukler wrote:
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.
Well, I do not think it is a Yes. I very much think it is a No. You
should have continued reading my
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
> > 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.
Well, I do not think it is a Yes. I very much think it is a No. You should have
continued reading my email 'til the middle or even far
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
rious changes to the OS, a solution
that would work for referenced vnodes is easier to implement.
igor.
-Original Message-
From: Robert Watson <[EMAIL PROTECTED]>
To: Sergey Uvarov <[EMAIL PROTECTED]>
Date: Mon, 5 Sep 2005 18:00:56 +0100 (BST)
Subject: Re: vn_fullpath() again
&
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
Hello hackers,
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
seems that linux_getcwd() app
20 matches
Mail list logo
