This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,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/