A new way of implementing symbolic links
Wolfgang R. Mueller
Would it be possible to totally eliminate inode usage for symbolic links
by simply putting the referenced filename into the directory itself ?
Then the additional disk access for the inode block could be saved.
I know that (all?) unixes do it via inodes nowadays, but I didn't find
any (real world!) usage of the remaining attributes in an inode for a
symbolic link, and given the different filesystem types existing, no
reliable program (except kernel, kernel modules, mk*fs, *fsck) should
access directories in a way revealing the embedded symbolic links.
Or am I totally wrong ?
Wolfgang R. Mueller <wolfgang...@uni-duesseldorf.de>,
Computing Centre, Heinrich-Heine-University, Duesseldorf, Germany.
Wayne Schlitt
>
> Just an idea:
> Would it be possible to totally eliminate inode usage for symbolic links
> by simply putting the referenced filename into the directory itself ?
Then how would you be able to link symbolic links together? Or are
you proposing a special kind of file that can't be linked and has to
be handled as a special case by every program that does a link?
*yetch*. IMHO, this is a _bad_ idea.
-wayne
--
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.
S. Joel Katz
>In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
>>
>> Just an idea:
>> Would it be possible to totally eliminate inode usage for symbolic links
>> by simply putting the referenced filename into the directory itself ?
>Then how would you be able to link symbolic links together? Or are
>you proposing a special kind of file that can't be linked and has to
>be handled as a special case by every program that does a link?
>*yetch*. IMHO, this is a _bad_ idea.
Easy. The symlink stored in one directory would contain the name
of the symlink stored in the other directory.
Next objection?
--
S. Joel Katz Information on Objectivism, Linux, 8031s, and atheism
Stim...@Panix.COM is available at http://www.panix.com/~stimpson/
Alain Knaff
: In <WAYNE.95M...@backbone.uucp> wa...@backbone.uucp (Wayne Schlitt) writes:
: >In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
: >>
: >> Just an idea:
: >> Would it be possible to totally eliminate inode usage for symbolic links
: >> by simply putting the referenced filename into the directory itself ?
: >Then how would you be able to link symbolic links together? Or are
: >you proposing a special kind of file that can't be linked and has to
: >be handled as a special case by every program that does a link?
: >*yetch*. IMHO, this is a _bad_ idea.
: Easy. The symlink stored in one directory would contain the name
: of the symlink stored in the other directory.
: Next objection?
Maybe he was thinking of *hard* linking symlinks together? But this
point is moot, because although the filesystem could permit this,
there is no system call that would allow the user to do it: Trying to
make a hard link to a symlink will really make a hard link to the file
pointed by the symlink.
--
Alain
Boris Tobotras
> Would it be possible to totally eliminate inode usage for symbolic links
> by simply putting the referenced filename into the directory itself ?
How are you going to fit (probably infinite length) filename into
directory entry?
--
Best regards, -- Boris. PGP OK
bo...@xtalk.msk.su AKA 2:5020/20.7 AKA 2:5020/188.21
Andre Fachat
: I know that (all?) unixes do it via inodes nowadays, but I didn't find
: any (real world!) usage of the remaining attributes in an inode for a
: symbolic link, and given the different filesystem types existing, no
As far as I know, the ext2 filesystem standard uses "short links" or whatever
they are called, saving the link itself in the inode completely, not using
an extra file for it.
So the extra fields are used to save the link. This of course only works
when the link fits into the inode. Otherwise a 'normal' file is used to
save the link information.
Andre
--
Andre Fachat mail me! fac...@galileo.rhein-neckar.de
FIDO: Andre Fachat@2:2468/6020.4 GERNET: Andre Fachat@21:100/3338.4
6502 - no hardware floating point division errors guaranteed!
Jonathan Kamens
|> How are you going to fit (probably infinite length) filename into
|> directory entry?
Easy -- you store the symbolic link name in the directory entry only if it
will actually fit; if not, you store it in a file with an inode, as symbolic
links are stored now.
This is not a new idea -- it has been implemented in UNIX filesystems in the
past, although I forget which ones. My brain is saying Apollo, but I don't
really know that for sure.
Erik Corry
: S. Joel Katz (stim...@panix.com) wrote:
: : In <WAYNE.95M...@backbone.uucp> wa...@backbone.uucp (Wayne Schlitt) writes:
: : >In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
: : >>
: : >> Just an idea:
: : >> Would it be possible to totally eliminate inode usage for symbolic links
: : >> by simply putting the referenced filename into the directory itself ?
: : >Then how would you be able to link symbolic links together? Or are
: : >you proposing a special kind of file that can't be linked and has to
: : >be handled as a special case by every program that does a link?
: : >*yetch*. IMHO, this is a _bad_ idea.
: : Easy. The symlink stored in one directory would contain the name
: : of the symlink stored in the other directory.
This is how symlinks work anywhay isn't it.
: : Next objection?
: Maybe he was thinking of *hard* linking symlinks together? But this
: point is moot, because although the filesystem could permit this,
: there is no system call that would allow the user to do it: Trying to
: make a hard link to a symlink will really make a hard link to the file
: pointed by the symlink.
What would you put in the inode field when somebody does an lstat on a
link? I'm not sure whether this is ever a useful thing to do, but
at the moment you will get an inode number which will be unique on the
device.
--
Erik Corry, Freiburg, Germany, +49 761 406637 er...@kroete2.freinet.de
Peter Mutsaers
BT> Wed, 15 Mar 1995 11:45:38 GMT Wolfgang R. Mueller wrote:
>> Would it be possible to totally eliminate inode usage for symbolic links
>> by simply putting the referenced filename into the directory itself ?
BT> How are you going to fit (probably infinite length) filename into
BT> directory entry?
Not infinite, but still it won't fit. Often (I don't have the exact
number for Linux at hand) the length for a directory entry is 255
maximum, and the maximum length of the total path is 1024.
But maybe something with more than one directory entry could be used
if necessary (the minority of cases)? That would be an ugly hack of
course.
--
Peter Mutsaers | AT Computing bv, P.O. Box 1428,
p...@atcmp.nl | 6501 BK Nijmegen, The Netherlands
tel. work: +31 (0)80 527248 |
tel. home: +31 (0)3405 71093 | "Trust me, I know what I'm doing."
Chris Bitmead
>>In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
>>>
>>> Just an idea:
>>> Would it be possible to totally eliminate inode usage for symbolic links
>>> by simply putting the referenced filename into the directory itself ?
>
>>Then how would you be able to link symbolic links together? Or are
>>you proposing a special kind of file that can't be linked and has to
>>be handled as a special case by every program that does a link?
>
>>*yetch*. IMHO, this is a _bad_ idea.
>
> Easy. The symlink stored in one directory would contain the name
>of the symlink stored in the other directory.
>
> Next objection?
I believe that one of the freebsds has or had an implementation of
symlinks where the link name was stored in the directory block, thus
saving a block. I believe they still had inodes however (I could be
wrong).
--
Chris Bitmead
chr...@ind.tansu.com.au
Franz Josef
: >> Would it be possible to totally eliminate inode usage for symbolic links
: >> by simply putting the referenced filename into the directory itself ?
Well, and if you want to create a symbolic link across filesystems
it won't work.
Bye, Juergen
juergen heinzl ido...@scn.de
Wayne Schlitt
> S. Joel Katz (stim...@panix.com) wrote:
> : In <WAYNE.95M...@backbone.uucp> wa...@backbone.uucp (Wayne Schlitt) writes:
>
> : >In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
> : >>
> : >> by simply putting the referenced filename into the directory itself ?
>
> : >Then how would you be able to link symbolic links together?
>
> : of the symlink stored in the other directory.
>
Yes. You can create a hard link to any file that has an inode.
> But this
> point is moot, because although the filesystem could permit this,
> there is no system call that would allow the user to do it:
Huh? what do you think the link(2) system call does?
> Trying to
> make a hard link to a symlink will really make a hard link to the file
> pointed by the symlink.
no. It makes a hard link to the symbolic link.
Observe:
Script started on Fri Mar 17 18:55:55 1995
(wayne 2) %% touch foo
(wayne 3) %% ln -s foo bar
(wayne 4) %% ls -l
total 2
lrwxrwxrwx 1 wayne develop 3 Mar 17 18:56 bar -> foo
-rw-rw---- 1 wayne develop 0 Mar 17 18:56 foo
(wayne 5) %% echo "asdf" >foo
(wayne 6) %% cat bar
asdf
(wayne 7) %% ln bar baz
(wayne 8) %% ls -l
total 6
lrwxrwxrwx 2 wayne develop 3 Mar 17 18:56 bar -> foo
lrwxrwxrwx 2 wayne develop 3 Mar 17 18:56 baz -> foo
-rw-rw---- 1 wayne develop 5 Mar 17 18:56 foo
(wayne 9) %% cat baz
asdf
(wayne 10) %% rm bar
(wayne 11) %% ls -l
total 4
lrwxrwxrwx 1 wayne develop 3 Mar 17 18:56 baz -> foo
-rw-rw---- 1 wayne develop 6 Mar 17 18:57 foo
(wayne 12) %% echo "xyzzy" >foo
(wayne 13) %% cat baz
xyzzy
script done on Fri Mar 17 18:57:26 1995
This type of operation can not be done if the symbolic link is just
stored in the directory and not as an inode. Hard links are one of
the big reasons to _have_ inodes. If you want to break hard links,
you could just move all the info from the inode into the directory
entry.
Come on folks. This is Unix file system semantics 101 here...
Chris Adams
Wayne Schlitt <wa...@cse.unl.edu> wrote:
>In article <3k8ut6$9...@imag.imag.fr> kn...@ngulu.imag.fr (Alain Knaff) writes:
>> Trying to
>> make a hard link to a symlink will really make a hard link to the file
>> pointed by the symlink.
>
>no. It makes a hard link to the symbolic link.
>
>
>Observe:
You should make sure that you are right before you tell someone else
they are wrong. I don't know what type of machine you did your script
on, but here is the script output of a similar example on a Linux
machine (ext2 filesystem):
Script started on Fri Mar 17 20:57:06 1995
ec119:1:~/tmp$ echo "xyzzy" > foo
ec119:2:~/tmp$ ln -s foo bar
ec119:3:~/tmp$ ls -l
total 1
lrwxrwxrwx 1 chris users 3 Mar 17 20:57 bar -> foo
-rw-r--r-- 1 chris users 6 Mar 17 20:57 foo
ec119:4:~/tmp$ ln bar baz
ec119:5:~/tmp$ ls -l
total 2
lrwxrwxrwx 1 chris users 3 Mar 17 20:57 bar -> foo
-rw-r--r-- 2 chris users 6 Mar 17 20:57 baz
-rw-r--r-- 2 chris users 6 Mar 17 20:57 foo
ec119:6:~/tmp$ exit
Script done on Fri Mar 17 20:57:46 1995
So you see, making a hard link to a symbolic link creates a hard link to
the file pointed to by the soft link. If you try to create a hard link
to a symbolic link that points to a nonexistant file, you get an error.
--
Chris Adams - ch...@ec119.residence.gatech.edu - Computer Science
PGP key available: http://ec119.residence.gatech.edu/~chris
AKA: ch...@cc.gatech.edu, gt8...@prism.gatech.edu
Abandon all hope, ye who PRESS ENTER here.
Alain Knaff
: Alain Knaff (kn...@ngulu.imag.fr) wrote:
: : S. Joel Katz (stim...@panix.com) wrote:
: : : In <WAYNE.95M...@backbone.uucp> wa...@backbone.uucp (Wayne Schlitt) writes:
: : : >In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
: : : >>
: : : >> Just an idea:
: : : >> Would it be possible to totally eliminate inode usage for symbolic links
: : : >> by simply putting the referenced filename into the directory itself ?
: : : >Then how would you be able to link symbolic links together? Or are
: : : >you proposing a special kind of file that can't be linked and has to
: : : >be handled as a special case by every program that does a link?
: : : >*yetch*. IMHO, this is a _bad_ idea.
: : : Easy. The symlink stored in one directory would contain the name
: : : of the symlink stored in the other directory.
: This is how symlinks work anywhay isn't it.
No. The names are either stored in the inode (short names) or in a "file"
(name too long to fit into inode)
: : : Next objection?
: : Maybe he was thinking of *hard* linking symlinks together? But this
: : point is moot, because although the filesystem could permit this,
: : there is no system call that would allow the user to do it: Trying to
: : make a hard link to a symlink will really make a hard link to the file
: : pointed by the symlink.
Well, this might not be true for all Unices, but it is for Linux, Ultrix and
SunOs. I even tried it with /bin/sh to make sure that the shell is not
playing any smart tricks on me.
: What would you put in the inode field when somebody does an lstat on a
: link? I'm not sure whether this is ever a useful thing to do, but
: at the moment you will get an inode number which will be unique on the
: device.
Good point.
--
Alain
Alain Knaff
: In article <WAYNE.95M...@backbone.uucp>,
: Wayne Schlitt <wa...@cse.unl.edu> wrote:
: >In article <3k8ut6$9...@imag.imag.fr> kn...@ngulu.imag.fr (Alain Knaff) writes:
: >> Trying to
: >> make a hard link to a symlink will really make a hard link to the file
: >> pointed by the symlink.
: >
: >no. It makes a hard link to the symbolic link.
: >
: >
: >Observe:
: [script output deleted]
: You should make sure that you are right before you tell someone else
: they are wrong. I don't know what type of machine you did your script
: on, but here is the script output of a similar example on a Linux
: machine (ext2 filesystem):
He was probably trying his script on Solaris.
Ultrix, AIX and SunOS behave the way Linux behaves, so Linux is probably right.
This is not a "SystemV vs BSD" issue either, as AIX is Sytem V as well.
--
Alain
David Kastrup
>You should make sure that you are right before you tell someone else
>they are wrong. I don't know what type of machine you did your script
>on, but here is the script output of a similar example on a Linux
>machine (ext2 filesystem):
>Script started on Fri Mar 17 20:57:06 1995
>ec119:1:~/tmp$ echo "xyzzy" > foo
>ec119:2:~/tmp$ ln -s foo bar
>ec119:3:~/tmp$ ls -l
>total 1
>lrwxrwxrwx 1 chris users 3 Mar 17 20:57 bar -> foo
>-rw-r--r-- 1 chris users 6 Mar 17 20:57 foo
>ec119:4:~/tmp$ ln bar baz
>ec119:5:~/tmp$ ls -l
>total 2
>lrwxrwxrwx 1 chris users 3 Mar 17 20:57 bar -> foo
>-rw-r--r-- 2 chris users 6 Mar 17 20:57 baz
>-rw-r--r-- 2 chris users 6 Mar 17 20:57 foo
>ec119:6:~/tmp$ exit
>Script done on Fri Mar 17 20:57:46 1995
>So you see, making a hard link to a symbolic link creates a hard link to
>the file pointed to by the soft link. If you try to create a hard link
>to a symbolic link that points to a nonexistant file, you get an error.
Your script proves *nothing*. Note that here you are *not* using the
link system call, but the GNU utility ln. This utility is smart
enough not to make hard links to symbolic links. To really test
this, you should use a C program. Adn, of course, to *really*
test this, you should do the system call in Assembler, because
one does not know what wrappers the C library puts around system
calls. For practical purposes, however, testing those conditions
that will hold for programs using the standard library should
be good enough, so testing it with the link library subroutine
should be sufficient.
--
David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419
Email: d...@pool.informatik.rwth-aachen.de Fax: +49-241-79502
Casper H.S. Dik
> He was probably trying his script on Solaris.
>Ultrix, AIX and SunOS behave the way Linux behaves, so Linux is probably right.
>This is not a "SystemV vs BSD" issue either, as AIX is Sytem V as well.
It is a BSD vs SYSV thing. IRIX 5.x and Solaris 2.x both make the hard
link to the symlink and not the symlink's target.
AIX is not SYSV. It's kind of nothing.
Casper
Alain Knaff
: ch...@ec119.residence.gatech.edu (Chris Adams) writes:
"Smart enough" infers that this would be a good thing. Why would this be
a good thing?
: To really test
: this, you should use a C program.
I did the same tests, and used a C program on Linux, same behaviour. (I
didn't do this on the other systems I tested, though)
: Adn, of course, to *really*
: test this, you should do the system call in Assembler, because
: one does not know what wrappers the C library puts around system
: calls.
I did my tests using my zlibc as C library. Zlibc intercepts a number of
syscalls, including link, in order to emulate a compressed file system.
It does not check for symlinks :-)
: For practical purposes, however, testing those conditions
: that will hold for programs using the standard library should
: be good enough, so testing it with the link library subroutine
: should be sufficient.
: --
: David Kastrup, Goethestr. 20, D-52064 Aachen Tel: +49-241-72419
: Email: d...@pool.informatik.rwth-aachen.de Fax: +49-241-79502
--
Alain
Wayne Schlitt
> : >
> : >no. It makes a hard link to the symbolic link.
> : >
> : on, but here is the script output of a similar example on a Linux
> : machine (ext2 filesystem):
>
> He was probably trying his script on Solaris.
Close. SVR4
> Ultrix, AIX and SunOS behave the way Linux behaves, so Linux is probably right.
It appears that HP/UX and BSDI also behave as Linux does, but SVR4,
HP/UX, SunOS, etc. all claim to be POSIX compliant. One unfortunate
aspect of the POSIX standard is that it allows many "options". You
can be POSIX compliant without long file names and symbolic links. It
is hard to say who is "right". Sadly, this may be a case where both
behaviors are considered right, and programs have to worry about the
peculiarities of both cases. *yetch*.
Personally, I find the non-SVR4 behavior bazaar. It means that you
can get errors when trying to link two files in the same directory
because one happens to be a symbolic link that crosses a file system.
It also means that I am not making a link to the name of the file that
I told it to. The file pointed to by a symbolic link can change
depending on what is mounted where. It is a fairly common practice to
leave "skeleton" filesystems under a mount point so that if the mount
fails, you still have a usable system.
Frank Lofaro
>It is a BSD vs SYSV thing. IRIX 5.x and Solaris 2.x both make the hard
>link to the symlink and not the symlink's target.
>
>AIX is not SYSV. It's kind of nothing.
>
>Casper
If the OS makes the hard-link to the symlink and the user did not want
this, the user (or a user program, or even a library) could follow the
link and do the link call using the target file as an argument.
If the OS does as Linux currently does, i.e. follow the symlink
itself, there is no way to make the hardlink to the symlink itself
(and the call fails utterly with an error if the link point
nowhere). No user mode fix can apply here.
A user might indeed want to make a hard link to a symlink in some
cases.
I patched linux to not follow symlinks when making a hard link. It
just required changing a namei to an lnamei (a one character
change!). (namei follows links, lnamei does not, like stat and lstat)
Here it is. It works fine. It is against 1.1.75, but I don't think it
should be hard to put in any kernel.
diff -r -u -N --horizon-lines=1000 linux.dist/fs/namei.c
linux/fs/namei.c
--- linux.dist/fs/namei.c Mon Nov 21 19:07:02 1994
+++ linux/fs/namei.c Sun Jan 1 07:25:39 1995
@@ -750,7 +750,7 @@
char * to;
struct inode * oldinode;
- error = namei(oldname, &oldinode);
+ error = lnamei(oldname, &oldinode);
if (error)
return error;
error = getname(newname,&to);
Tim Smith
>Your script proves *nothing*. Note that here you are *not* using the
>link system call, but the GNU utility ln. This utility is smart
>enough not to make hard links to symbolic links. To really test
Wrong. If you run his example with strace, you'll see that his
ln bar baz
gets rather directly turned into
link("bar","baz")
by GNU ln.
--Tim Smith
ps: A/UX behaves the same way Linux does.
Andries Brouwer
: It appears that HP/UX and BSDI also behave as Linux does, but SVR4,
: HP/UX, SunOS, etc. all claim to be POSIX compliant. One unfortunate
: aspect of the POSIX standard is that it allows many "options". You
: can be POSIX compliant without long file names and symbolic links. It
: is hard to say who is "right". Sadly, this may be a case where both
: behaviors are considered right, and programs have to worry about the
: peculiarities of both cases. *yetch*.
POSIX 1003.1 (1990) B.5.3.4:
"Symbolic links are not discussed by POSIX.1".
Also the X/Open portability guide does not mention symbolic links.
So, yes, use of symbolic links is nonportable (let alone
reliance on subtleties about the behaviour of linking to links).
Unfortunately, sometimes one has to test for the presence of
symbolic links.
Jay Ashworth
) In article <WAYNE.95M...@backbone.uucp>,
) Wayne Schlitt <wa...@cse.unl.edu> wrote:
) >no. It makes a hard link to the symbolic link.
) >Observe:
) [script output deleted]
) You should make sure that you are right before you tell someone else
) they are wrong. I don't know what type of machine you did your script
) on, but here is the script output of a similar example on a Linux
) machine (ext2 filesystem):
Chris, I agree with you... but why didn't _anyone_ use ls _-i_?
Cheers,
-- jra
--
Jay R. Ashworth High Technology Systems Consulting Ashworth
Designer Linux: The Choice of a GNU Generation & Associates
ka1fjx/4 "Civil Liberty Through Complex Mathematics" +1 813 790 7592
j...@baylink.com -- Michael Handler, in news.admin.policy NIC: jra3
Jay Ashworth
Amen.
AIX is some IBM proprietary thingie with a Unix skin on top.
Just ask an AIX sysadmin.
Cheers,
-- jr'Whip me, Beat me, Make me administer AIX' a
Nick Holloway
> HP/UX, SunOS, etc. all claim to be POSIX compliant. One unfortunate
> aspect of the POSIX standard is that it allows many "options". You
> can be POSIX compliant without long file names and symbolic links. It
> is hard to say who is "right". Sadly, this may be a case where both
> behaviors are considered right, and programs have to worry about the
> peculiarities of both cases. *yetch*.
I once wanted to check the behaviour of Linux against POSIX when I came
across something symlink specific. Unfortunately, since symlinks are
not required by POSIX, the actual behaviour of symlinks as required by
POSIX is ``implementation defined''. Big :-(.
You've just raised awareness of another anomoly of symlinks between
systems. The others that come to mind are that chmod changes the
permission of the target, whereas chown changes the ownership of the link
(which is why some systems have lchown to change the owenership of the
target -- or is that the other way around? On some systems?).
So, in summary POSIX won't help you with symlinks, for acceptable
behaviour you need to take a mixture of what is acceptable, and
compatible. One possible question of Linux development, is should it have
sys_lchown for compatability (easy to implement, but is it desirable)?
--
Nick Holloway | `O O' | Home: Nick.H...@alfie.demon.co.uk
[aka `Alfie'] | // ^ \\ | Work: Nick.H...@parallax.co.uk
Asociacion Fisica Universidad
On Thu, 16 Mar 1995, Wayne Schlitt wrote:
> In article <wolfgang.muelle...@uni-duesseldorf.de> wolfgang...@uni-duesseldorf.de (Wolfgang R. Mueller) writes:
> >
> > Just an idea:
> > Would it be possible to totally eliminate inode usage for symbolic links
> > by simply putting the referenced filename into the directory itself ?
>
> Then how would you be able to link symbolic links together? Or are
> you proposing a special kind of file that can't be linked and has to
> be handled as a special case by every program that does a link?
I don't understand exactly what d'you mean? You say that we could
not do something like this:
ln -s /vmlinux-1.2.0 /boot/kernel-1.2.0
ln -s /boot/kernel-1.2.0 /kernel
If what I think you say is this, then the kernel, when finding
the inode to read from, only would have to search until it finds a real
file, and not a link ...
If I'm wrong, throw to /dev/null what I said before and explain
it to me, please :)
Greetings
Iñaky Perez Gonzalez <The Physics Failer> (af...@fis.ucm.es, 2:341/5.31)
*** Opinions are my own. I don't speak for Asociacion Fisica Universidad (AFU)
*** Opiniones propias. No hablo por la Asociacion Fisica Universidad (AFU)
*** Trough anyway ... every of us in AFU are like the same :)
<Frase ingeniosa pendiente de elaboración ... >
Adam J. Richter
>can get errors when trying to link two files in the same directory
>because one happens to be a symbolic link that crosses a file system.
>It also means that I am not making a link to the name of the file that
You could still get this behavior while storing symlinks
in the directory by having the operation making a hard link to
a symlink instead make a duplicate of the symlink. Of course, if
you lstat the symlink, you won't get a meaningful inode number or
link count, but that doesn't effect your concerns, and it may well
be worth the performance improvement and possible savings in disk space
in environments where users are constantly traversing symbolic links,
such as a distribution that makes lots of symlinks to a CDROM or source
trees that are symlinks to a "master" source tree.
--
Adam J. Richter Yggdrasil Computing, Incorporated
(408) 261-6630 "Free Software For The Rest of Us."