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 reference, not
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 a directory. The
[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 and not an alias
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 is a directory (not
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 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 the
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:
$ ln -s '' foo
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 Unsubscribe:
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
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
On Mon, 18 Jun 2001 15:40:23 +1000 (EST), Bruce Evans [EMAIL PROTECTED] 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,
On Mon, Jun 18, 2001 at 13:22:10 -0400, Garrett Wollman wrote:
On Mon, 18 Jun 2001 20:59:45 +0400, Andrey A. Chernov [EMAIL PROTECTED] said:
Maybe it is just my bad English understanding, but it seems last two cases
must be
./foo/ .//
./foo/bar .//bar
No,
On Mon, 18 Jun 2001 21:35:17 +0400, Andrey A. Chernov [EMAIL PROTECTED] 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
:On Mon, 18 Jun 2001 21:35:17 +0400, Andrey A. Chernov [EMAIL PROTECTED] 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
On Mon, 18 Jun 2001 10:46:27 -0700 (PDT), Matt Dillon [EMAIL PROTECTED]
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
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 unmounted
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) just
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 after
: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 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
: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.
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 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 you
:
: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
:
: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 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 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
: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
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 -symlinks
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 the
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 routine.
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 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' copying
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).
Maybe,
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
BE
BE This
On Sat, 16 Jun 2001 17:27:00 +1000 (EST)
Bruce Evans [EMAIL PROTECTED] wrote:
BEThis 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 copies file
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 because
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.
--
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
of things so it would be totally
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
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 create a
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 creation. It has,
:...
: 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* be
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 would break
44 matches
Mail list logo