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.


I agree with your points.  Approach #1 below would require modifications
to the move implementation as well.  Also, interaction with Windows tools
is important, and if you can only access hard-linked files through Cygwin,
their usefulness will be somewhat limited.  Approach #2 is more uniform,
but still doesn't address the interaction with Windows tools (the "hard
links" will be able to be moved and renamed by Windows tools, but not
actually read).  It's likely that a general solution is impossible
altogether, and copying the files *is* the best approximation.
	Igor
P.S. <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.

On Tue, 20 Apr 2004, Bill C. Riemers wrote:

> Hmmm.  I forgot one other advantage of symbolic links.  They are independent
                                         ^^^^^^^^^^^^^^
I believe you meant "hard links" here...

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


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