Dave reminds me...
The objective of some of the POSIX statements about symlinks was to
permit a "fast symlink" implementation where the symlinks did not appear
as inodes in the filesystem at all, but rather were "smart" directory
entries.
If a symlink has a link count (and thus can be the target of a hard
link) (or protections, or...) then "fast symlinks" become harder
(effectively impractical), and it dictates that symlinks be implemented
as inodes.
The old Apollo system did this, and I believe that there was at least
one other (I never knew if it went public) implementation.
As I remember, the decision was made back then to allow implementations
to support "fast symlinks". That decision is what's being revisited
now, but apparently without considering "fast symlinks" explicitly.
Donn
-----Original Message-----
From: David Korn [mailto:yyy@xxxxxxxxxxxxxxxx]
Sent: Thursday, March 17, 2005 6:38 AM
To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: Re: link(2) and symlinks
Back in the mid eighties when BSD has symlinks and System V didn't,
I modified added symlinks to a SVR3 kernel. Unlike the BSD
version, I had link no follow symlinks so that the reference
count on the symlink would be incremented. Thus, link() and unlink()
were the exceptions to follow. This more symmetrical behavior
allowed programs that used link()/unlink() to rename a file
to continue to work. There were some other nicer benefits
as well which I can't remember.
I tried to sell this idea to developers of SVR4 but they felt
that compatibility with BSD was more important.
I presented my views on this at POSIX meetings when symlinks()
were discussed but arguments they were not adopted.
One argument against this way was that it required a symlink
to have a reference count. POSIX did not want to require that
a symlink have any lstat() attribute other than a size.
David Korn
yyy@xxxxxxxxxxxxxxxx
|