On Fri, 31 Aug 2001, Terry Lambert wrote:
> Bruce Evans wrote:
> > No, the empty pathname has been invalid and not an alias for "." since at
> > least the first version of POSIX.
>
> That's the same time they broke signal restart and file
> locks, right?
Only the file locks :-).
Bruce
To Unsu
On Fri, 31 Aug 2001, Brian F. Feldman wrote:
> Bruce Evans <[EMAIL PROTECTED]> wrote:
> > On Fri, 31 Aug 2001, Brian F. Feldman wrote:
> >
> > > Bruce Evans <[EMAIL PROTECTED]> wrote:
> > > > Here's an example of a standard utility being clueless about symlinks to
> > > > nothing:
> > > >
> > > >
Bruce Evans wrote:
> No, the empty pathname has been invalid and not an alias for "." since at
> least the first version of POSIX.
That's the same time they broke signal restart and file
locks, right?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
This argument is just rehashing something that came up in June. Man
you people have short memories!
I comitted a fix to -current two months ago. It's still in my -stable
tree... if Jordan gives the O.K., I will MFC it to -stable.
Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Aug 2001, Brian F. Feldman wrote:
>
> > Bruce Evans <[EMAIL PROTECTED]> wrote:
> > > Here's an example of a standard utility being clueless about symlinks to
> > > nothing:
> > >
> > > $ ln -s '' foo
> > > $ cp foo bar
> > > cp: foo
[Attribution deleted for clarity; see referenced messages in the archives.]
>> > $ ln -s '' foo
>> > $ cp foo bar
>> > cp: foo is a directory (not copied)
>> No, "foo" certainly _is_ a directory. It is precisely the same thing as
>> ".".
> No, the empty pathname has been invalid an
On Fri, 31 Aug 2001, Brian F. Feldman wrote:
> Bruce Evans <[EMAIL PROTECTED]> wrote:
> > Here's an example of a standard utility being clueless about symlinks to
> > nothing:
> >
> > $ ln -s '' foo
> > $ cp foo bar
> > cp: foo is a directory (not copied)
> >
> > foo is certainly not
Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote:
>
> > On Fri, 15 Jun 2001 06:31:12 -0700 (PDT)
> > David Wolfskill <[EMAIL PROTECTED]> wrote:
> >
> > DW> Indeed: it is my understanding that the "path name" interpretation is
> > DW> an issue at the time of
On Sat, 23 Jun 2001, Matt Dillon wrote:
> Ok, Bruce... the symlink patch has been sitting in my tree for a week
> now. I am going to let you decide whether I should commit it or not.
> If not, into the trash heap it goes. This is likely to be the only
> way the problem will be s
Ok, Bruce... the symlink patch has been sitting in my tree for a week
now. I am going to let you decide whether I should commit it or not.
If not, into the trash heap it goes. This is likely to be the only
way the problem will be solved since creating an empty symlink via
the
> > So it seems to me the _use_ of a "" target symlink
> > (in all but the final path component position) is exactly
> > equivalent to the use of a "/" target symlink. When used in
> > the final path component position, you get either the symlink
> > or ENOENT. The POSIX excerpt Garrett quoted s
On Mon, 18 Jun 2001, Bakul Shah wrote:
> > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> > I like it, except it seems to be incompatible with POSIX.1-200x.
>
> > ... [not what "not quite" applies to]
>
> Err... not quite. Given a path like
> /
> after the sub
> < said:
>
> > Here's an example of a complication: what is the semantics of /tmp/foo/bar
> > where foo is a symlink to ""? I think the pathname resolves to
> > /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't
> > point anywhere.
>
> But this is at least consistent with
<
said:
> In anycase, I can't imagine that POSIX actually intended null
> symlinks to act in any particular way
The standard specifies precisely how pathname resolution is supposed
to behave. FreeBSD should conform to the standard, even if some of
the consequences are somewhat unexpected. (At
:< said:
:
:>> > ./foo/ .//
:>> > ./foo/bar .//bar
:>>
:>> No, because the ``resulting filename'' begins with a slash.
:
:> It seems resulting filename (pathname?) begins with "./" (not a slash).
:
:No, it doesn't. The ``resulting filename'' is "/" in the first case,
:and "/b
< said:
>> >./foo/ .//
>> >./foo/bar .//bar
>>
>> No, because the ``resulting filename'' begins with a slash.
> It seems resulting filename (pathname?) begins with "./" (not a slash).
No, it doesn't. The ``resulting filename'' is "/" in the first case,
and "/bar" in the
On Mon, Jun 18, 2001 at 13:22:10 -0400, Garrett Wollman wrote:
> < said:
>
> > Maybe it is just my bad English understanding, but it seems last two cases
> > must be
> > ./foo/ .//
> > ./foo/bar .//bar
>
> No, because the ``resulting filename'' begins with a slash.
It see
< said:
> Maybe it is just my bad English understanding, but it seems last two cases
> must be
> ./foo/ .//
> ./foo/bar .//bar
No, because the ``resulting filename'' begins with a slash.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
> The bug that stat(2) on a null symlink classifies the target of the symlink
> as a directory is caused by resolving the pathname to "" and then not
> r
On Mon, Jun 18, 2001 at 11:53:59 -0400, Garrett Wollman wrote:
> < said:
>
> > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> > I like it, except it seems to be incompatible with POSIX.1-200x.
>
> I think I agree with your interpretation. Quoting from XBDd7, page
>
< said:
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
I think I agree with your interpretation. Quoting from XBDd7, page
101, lines 3153ff:
# In all other cases, the system shall prefix the remain
On Sun, 17 Jun 2001, Matt Dillon wrote:
> Ok, this patch should do it. For review. I've made it return ENOENT,
> which is the same error that is returned when you try to open an empty
> path (e.g. open("", ...)).
>
> (Note: This is unrelated to Bruce's second issue with 'cp' co
Heh. We came up with virtually the same patch at the same time!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Jun 18, 2001 at 03:40:28 +0200, Assar Westerlund wrote:
>
> What about this?
>
Matt's variant is better because return ENOENT _before_ NAMETOOLONG check.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the b
:
:On Sun, Jun 17, 2001 at 21:16:24 -0400, Garance A Drosihn wrote:
:>
:> When I say this, I assume that the only change to make is how any
:> 'open' or 'stat' call will handle null symlinks. If I am reading
:> Andrey correctly, there will be no change to the 'ln' command or
:> the symlink() sy
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> I think that it's reasonable to just make it a specific error, and
> thus end this thread. No harm will come of making it a specific
> error on open, and it will address the problems mentioned earlier.
What about this?
/assar
Index: vfs_lookup.c
On Sun, Jun 17, 2001 at 21:16:24 -0400, Garance A Drosihn wrote:
>
> When I say this, I assume that the only change to make is how any
> 'open' or 'stat' call will handle null symlinks. If I am reading
> Andrey correctly, there will be no change to the 'ln' command or
> the symlink() system rout
On Sun, Jun 17, 2001 at 18:00:06 -0700, Matt Dillon wrote:
>
> I think we can safely disallow path lookups going through empty symlinks
> (i.e. at the time of the open(), lstat(), etc...), but we should not
> go changing the "ln" command or the symlink() system call.
This is exact t
At 2:28 PM -0700 6/17/01, Matt Dillon wrote:
>:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote:
>:> It seems your argument to disallow null symlinks got somehow taken
>:> as an argument to disallow all "invalid" symlinks then.
>:
>:
>:To say it more clear: now I even not against ""-sy
:There is nothing to fix. Sometimes 'make install' instead 'make
:installworld' typed can produce this. Of course, install procedure can be
:complicated to make it foolprof, but I think the system must be fixed
:instead to not resolve illegal names. It is not good idea to
:produce workarounds of
On Sun, Jun 17, 2001 at 17:26:16 -0700, Matt Dillon wrote:
>
> If something in the build is creating empty symlinks under certain
> circumstances, that something should be fixed. The problem isn't ln -s.
There is nothing to fix. Sometimes 'make install' instead 'make
installworld' typed
On Sun, Jun 17, 2001 at 17:01:08 -0700, Matt Dillon wrote:
> I'm sorry, I don't understand... what does this have to do with
> an empty symlink verses a symlink containing something else?
> 'rm' does not traverse symlinks.
I not mean 'rm' literally.
Read Bruce's comment about how fake
:
:On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote:
:>
:> What cases? In all my years of programming I've never once 'accidently'
:> created an empty symlink.
:
:See initial Bruce comments. Sometimes when 'make hierarchy' step is
:missing, intermediate result of 'make install'
:
:On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote:
:> What cases? In all my years of programming I've never once 'accidently'
:> created an empty symlink.
:
:The next example is fts-like activity - wrong final destination
:appearse which is dangerous for 'rm'. I.e. in some sit
On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote:
> What cases? In all my years of programming I've never once 'accidently'
> created an empty symlink.
The next example is fts-like activity - wrong final destination
appearse which is dangerous for 'rm'. I.e. in some situation yo
On Sun, Jun 17, 2001 at 15:04:06 -0700, Matt Dillon wrote:
>
> What cases? In all my years of programming I've never once 'accidently'
> created an empty symlink.
See initial Bruce comments. Sometimes when 'make hierarchy' step is
missing, intermediate result of 'make install' can't be
:On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote:
:
:> rather then trying to resolve it. I'm not sure it's worth it, though.
:> It just doesn't come up that often and there are a thousand other ways you
:> can hogtie yourself in the system that takes less effort.
:
:It wort
On Sun, Jun 17, 2001 at 14:28:40 -0700, Matt Dillon wrote:
> rather then trying to resolve it. I'm not sure it's worth it, though.
> It just doesn't come up that often and there are a thousand other ways you
> can hogtie yourself in the system that takes less effort.
It worth. It ca
:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote:
:> It seems your argument to disallow null symlinks got somehow taken
:> as an argument to disallow all "invalid" symlinks then.
:
:
:To say it more clear: now I even not against ""-symlinks making ability,
:such strings are valid per
On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote:
> It seems your argument to disallow null symlinks got somehow taken
> as an argument to disallow all "invalid" symlinks then.
To say it more clear: now I even not against ""-symlinks making ability,
such strings are valid per POSIX a
It seems your argument to disallow null symlinks got somehow taken
as an argument to disallow all "invalid" symlinks then.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sun, Jun 17, 2001 at 23:02:50 +1000, Bruce Evans wrote:
>
> So disallowing null symlinks would actually unbreak /etc/malloc.conf.
>
> Further debugging shows that the main bug is in the kernel.
> stat(2) on a null symlink bogusly succeeds and classifies the symlink
> as a directory. ln(1) ju
On Sat, 16 Jun 2001, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Steve O'Hara-Smith" writes:
> : I would argue loud and long that changing that *would* be broken. There
> : is never a guarantee (or even an implication) that a symlink points to a
> : valid directory entry (think unmou
In message <[EMAIL PROTECTED]> "Steve O'Hara-Smith" writes:
: I would argue loud and long that changing that *would* be broken. There
: is never a guarantee (or even an implication) that a symlink points to a
: valid directory entry (think unmounted filesystems, NFS ...). I find it hard
: to
In message <[EMAIL PROTECTED]> "Karsten W. Rohrbach" writes:
: > lrwxrwxr-x 1 david wheel 13 Jun 15 06:40 .netscape/lock -> 1.0.0.127:6=
: 12
: this is actually more performant than writing ascii text into a file and
: checking the file by opening and parsing it. you simply do not have to
: fop
:...
:>
:>True. It would break phk's malloc debugging features to disable this,
:>for example.
:
:Not only that, but considerning that a symlink can point into a
:different filesystem even in normal use, there is no simple way to
:validate the valididty of the name.
... or be associated with
In message <[EMAIL PROTECTED]>, Jordan Hubbard writes:
>From: Matt Dillon <[EMAIL PROTECTED]>
>Subject: Re: symlink(2) [Was: Re: tcsh.cat]
>Date: Fri, 15 Jun 2001 22:01:47 -0700 (PDT)
>
>> Symlinks do not have to contain paths. People use them for all sorts
&
On Sat, 16 Jun 2001 22:30:58 +1000 (EST)
Bruce Evans <[EMAIL PROTECTED]> wrote:
BE> cp always did this (except in the broken case of a broken symlink). POSIX
BE> just clarifies it. From the FreeBSD manpage for cp(1):
Ignore me, I think I must be going temporarily insane.
--
Direc
On Sat, 16 Jun 2001, Steve O'Hara-Smith wrote:
> On Sat, 16 Jun 2001 17:27:00 +1000 (EST)
> Bruce Evans <[EMAIL PROTECTED]> wrote:
>
>
> BE> > This is correct behaviour IMHO - why on earth should it fail. If I
> BE> > copy a directory containing symlinks I don't want them do vanish just
On Sat, 16 Jun 2001 17:27:00 +1000 (EST)
Bruce Evans <[EMAIL PROTECTED]> wrote:
BE> > This is correct behaviour IMHO - why on earth should it fail. If I
BE> > copy a directory containing symlinks I don't want them do vanish just because
BE> > the target is unavailable.
BE>
BE> Because cp copi
On Sat, 16 Jun 2001, Steve O'Hara-Smith wrote:
> On Sat, 16 Jun 2001 14:34:07 +1000 (EST)
> Bruce Evans <[EMAIL PROTECTED]> wrote:
> BE> cp is also broken for symlinks to valid pathnames for nonexistent files;
> BE>
> BE> $ rm -f foo
> BE> $ ln -s /nonesuch foo
> BE> $ cp foo bar
>
On Sat, 16 Jun 2001 14:34:07 +1000 (EST)
Bruce Evans <[EMAIL PROTECTED]> wrote:
BE> We are (or at least I am) talking about changing it to prevent links to a
BE> string that can _never_ be a valid pathname. Fortunately, in POSIX there
BE> is only one such string (the empty string).
Mayb
From: Matt Dillon <[EMAIL PROTECTED]>
Subject: Re: symlink(2) [Was: Re: tcsh.cat]
Date: Fri, 15 Jun 2001 22:01:47 -0700 (PDT)
> Symlinks do not have to contain paths. People use them for all sorts
> of things so it would be totally inappropriate to put any sort of
True. It
:...
:> It has been on evey platform I have ever used ln -s on.
:>
:> DW> One may well argue that this is "broken" in some way(s). Still, changing
:> DW> it at this point could well be considered a POLA violation, at best.
:>
:> I would argue loud and long that changing that *would*
On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote:
> On Fri, 15 Jun 2001 06:31:12 -0700 (PDT)
> David Wolfskill <[EMAIL PROTECTED]> wrote:
>
> DW> Indeed: it is my understanding that the "path name" interpretation is
> DW> an issue at the time of reference, not (necessarily) the time of
> DW> creati
On Fri, Jun 15, 2001 at 02:08:03PM +0100, Richard Tobin wrote:
> > P>The string pointed to by path1 shall be treated only as a character
> > P>string and shall not be validated as a pathname.
>
> I have heard on several occasions of peope using symlink(2) to
> atomically store some small
< said:
> POSIX explicitly disallow "" filenames everywhere. I think it should be
> so for symlinks too.
But it doesn't, and that's the end of it for at least another five
years.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the me
On Fri, Jun 15, 2001 at 15:53:10 -0400, Garrett Wollman wrote:
> < said:
>
> > Here's an example of a complication: what is the semantics of /tmp/foo/bar
> > where foo is a symlink to ""? I think the pathname resolves to
> > /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn'
< said:
> Maybe, but this doesn't seem to be permitted by POSIX.1-200x:
The response I got to a similar question about symbolic links suggests
that the definition of ``path name resolution'' is supposed to be the
final word on the meaning and interpretation of symbolic links.
-GAWollman
To Un
< said:
> Here's an example of a complication: what is the semantics of /tmp/foo/bar
> where foo is a symlink to ""? I think the pathname resolves to
> /tmp//bar and then to /tmp/bar, but this is surprising since foo doesn't
> point anywhere.
But this is at least consistent with the historic (p
On Fri, 15 Jun 2001 06:31:12 -0700 (PDT)
David Wolfskill <[EMAIL PROTECTED]> wrote:
DW> Indeed: it is my understanding that the "path name" interpretation is
DW> an issue at the time of reference, not (necessarily) the time of
DW> creation. It has, to the best of my knowledge, been valid to crea
David Wolfskill([EMAIL PROTECTED])@2001.06.15 06:53:27 +:
> And another:
>
> dhcp-133[1] ls -l .netscape/lock
> lrwxrwxr-x 1 david wheel 13 Jun 15 06:40 .netscape/lock -> 1.0.0.127:612
>
> :-},
> david (making no claims about what is "good practice", here)
this is actually more performa
Andrey A. Chernov([EMAIL PROTECTED])@2001.06.15 16:02:50 +:
> On Fri, Jun 15, 2001 at 13:15:04 +1000, Bruce Evans wrote:
>
> > Related bugs:
> > - symlink(2) is happy to create a symlink to the empty pathname although
> > empty pathnames are invalid.
>
> Maybe we need to fix symlink(2) the
>Date: Fri, 15 Jun 2001 23:33:07 +1000 (EST)
>From: Bruce Evans <[EMAIL PROTECTED]>
>> I have heard on several occasions of peope using symlink(2) to
>> atomically store some small piece of information for locking purposes.
>> (Symlink was more reliably atomic over NFS than other methods.) So it
On Fri, 15 Jun 2001, Richard Tobin wrote:
> > P>The string pointed to by path1 shall be treated only as a character
> > P>string and shall not be validated as a pathname.
>
> I have heard on several occasions of peope using symlink(2) to
> atomically store some small piece of information
>Date: Fri, 15 Jun 2001 22:57:56 +1000 (EST)
>From: Bruce Evans <[EMAIL PROTECTED]>
>> Maybe we need to fix symlink(2) then ?
>Maybe, but this doesn't seem to be permitted by POSIX.1-200x:
>P>int symlink(const char *path1, const char *path2);
>P>...
>P>The string pointed to by path1
> P>The string pointed to by path1 shall be treated only as a character
> P>string and shall not be validated as a pathname.
I have heard on several occasions of peope using symlink(2) to
atomically store some small piece of information for locking purposes.
(Symlink was more reliably ato
On Fri, 15 Jun 2001, Andrey A. Chernov wrote:
> On Fri, Jun 15, 2001 at 13:15:04 +1000, Bruce Evans wrote:
>
> > Related bugs:
> > - symlink(2) is happy to create a symlink to the empty pathname although
> > empty pathnames are invalid.
>
> Maybe we need to fix symlink(2) then ?
Maybe, but t
On Fri, Jun 15, 2001 at 13:15:04 +1000, Bruce Evans wrote:
> Related bugs:
> - symlink(2) is happy to create a symlink to the empty pathname although
> empty pathnames are invalid.
Maybe we need to fix symlink(2) then ?
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [E
On Fri, 15 Jun 2001, Andrey A. Chernov wrote:
> On Thu, Jun 14, 2001 at 22:53:25 +0100, Adrian Browne wrote:
> >
> > Hi folks I'm having a prob with tcsh.cat when performing a a make install
> > after a buildworld and can't seem to shrug it off and or find a re
On Thu, Jun 14, 2001 at 22:53:25 +0100, Adrian Browne wrote:
>
> Hi folks I'm having a prob with tcsh.cat when performing a a make install
> after a buildworld and can't seem to shrug it off and or find a reason to
> it's occurance does any one know of a fix as I cant
Hi folks I'm having a prob with tcsh.cat when performing a a make install
after a buildworld and can't seem to shrug it off and or find a reason to
it's occurance does any one know of a fix as I cant go any further :(
/bin/tcsh -> /bin/csh
install -c -o root -g wheel -m
72 matches
Mail list logo
