Hmmm. I forgot one other advantage of symbolic links. They are independent
of the locations of each other. i.e.
touch /tmp/foo.txt
ln /tmp/foo.txt /home/bcr/foo.txt
mkdir /home/bcr/tmp
mv /tmp/foo.txt /home/bcr/tmp/foo.txt
Both versions of foo.txt are still valid, even though they would not be with
a symbolic link.
I do not see a good way to reproduce all the behaviors of a hardlink without
underlying filesystem support. Take for example, if we do just
rename the original file and put in a symlink. How do we make sure the link
count remains valid even after the user uses Windows tools to rename a
directory, copy a directory, or delete a directory?
I guess how sophisticated the solution needs to be depends on why hardlinks
are needed.
Bill
----- Original Message -----
From: "Igor Pechtchanski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Buchbinder, Barry (NIH/NIAID)" <[EMAIL PROTECTED]>; "'A. Alper
Atici'" <[EMAIL PROTECTED]>
Sent: Tuesday, April 20, 2004 3:02 PM
Subject: RE: Emulating hard links on FAT et al.
> Replying to myself -- bad habits die hard... Just to dot all the "i"s and
> cross all the "t"s.
>
> One thing I forgot to mention is how to handle link counts. Those could
> be stored in, for example, the NTEA attributes file for the original (or
> the corresponding special) filename. I don't see anything wrong with
> requiring NTEA on FAT in order to have hard links, BTW.
> Igor
>
> On Tue, 20 Apr 2004, Igor Pechtchanski wrote:
>
> > A hard link is made to a file on disk, whereas a symbolic link is made
to
> > a directory entry. Once a hard link is made, it's indistinguishable
from
> > the original file. Essentially, *each* directory entry is a hard link
to
> > the contents of the corresponding file, and the link count of any hard
> > link to the same file should reflect the total number of hard links.
> > Also, deleting one hard link does not result in the deletion of the file
> > -- the file is only deleted when all of the corresponding hard links
have
> > been removed (incidentally, that's why the remove operation in Unix is
> > performed by an unlink() system call).
> > Another, less taxing property of hard links is that the inode number of
> > all hard links to the same file is the same.
> >
> > The closest FAT comes to the notion of true hard links are cross-linked
> > files, and those are illegal. Frankly, I think it would be a very hard
> > problem to implement a reasonable emulation of hard links without
> > filesystem support (e.g., on FAT). FWIW, here are a couple of ideas
> > (brainstorm-style, hope they are helpful):
> >
> > 1) If hard links are implemented as just another type of symlink, then
> > every unlink() call will need to enumerate all of the other "hard links"
> > to the file, move the file to one of those names, and then change all
the
> > others to point to the new location of the file. This would really slow
> > down every unlink() call, AFAICS.
> >
> > 2) Alternatively, upon creating the first hard link the file could be
> > renamed to some internal name (that should be invisible via Cygwin), and
> > the original name will also become a "hard link". This way, the unlink
> > code will not have to be changed, but all of the relevant file and
> > directory handling code will need to be "taught" to ignore those special
> > names.
> >
> > In both cases, the inode computation code in all incarnations of stat()
> > will need to be changed to dereference a "hard link" and compute the
inode
> > number of the original file. Also, at least the open() system call
> > (possibly others) will need to be changed to get to the correct file.
> >
> > HTH,
> > Igor
> >
> > On Tue, 20 Apr 2004, Buchbinder, Barry (NIH/NIAID) wrote:
> >
> > > If you do this, remember that it shouldn't be limited to FAT file
systems.
> > > Even though one's version of Windows may be capable of making hard
links,
> > > one may not have the permission level (Administrator) to do so.
> > >
> > > But I'm not sure that I see the point of emulating hard links. It
seems to
> > > me that you are just making a second type of symbolic link. Is there
> > > anything that the emulated hard link could do that the ordinary
symbolic
> > > link cannot? (Sorry if this is a question with an obvious answer. I
> > > haven't had more than fleeting access to a system that would allow me
to
> > > make hard links since 1988).
> > >
> > > -----Original Message-----
> > > From: A. Alper Atici
> > > Sent: Monday, April 19, 2004 5:52 PM
> > > To: cygwin<at>cygwin<dot>com
> > > Subject: RFI: Emulating hard links on FAT et al.
> > >
> > > Hello,
> > >
> > > I've been pondering over the prospects of emulating hard links for
> > > some time. List archives don't show much about it, and I have not come
> > > across any similar open implementation on the net.
> > >
> > > My rudimentary idea of emulating hard links is based on employing a
> > > new type of windows shortcut which will be regarded as a hardlinking
> > > file, rather than a symlink, by Cygwin. For this, I hope to figure out
> > > a possible combination in the magic bitvector byte(word?) in shortcut
> > > header. Any comments? How about 0x1c?
> > > --
> > > A. Alper Atici OpenPGP KeyID: 0xB824F550
>
> --
> http://cs.nyu.edu/~pechtcha/
> |\ _,,,---,,_ [EMAIL PROTECTED]
> ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED]
> |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
>
> "I have since come to realize that being between your mentor and his route
> to the bathroom is a major career booster." -- Patrick Naughton
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Problem reports: http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
