This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Emulating hard links on FAT et al.


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" <pechtcha@cs.nyu.edu>
To: <cygwin@cygwin.com>
Cc: "Buchbinder, Barry (NIH/NIAID)" <BBuchbinder@niaid.nih.gov>; "'A. Alper
Atici'" <alperatici@ttnet.net.tr>
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/
>       |\      _,,,---,,_ 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/
>



--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]