Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Authentication-Warning: slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date: Tue, 20 Apr 2004 15:02:18 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
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>
Subject: RE: Emulating hard links on FAT et al.
In-Reply-To: <Pine.GSO.4.56.0404201434290.4141@slinky.cs.nyu.edu>
Message-ID: <Pine.GSO.4.56.0404201459540.4141@slinky.cs.nyu.edu>
References: <F76C9B2DA2FC4C4CA0A18E288BBCBCF7082177FA AT nihexchange24 DOT nih DOT gov> <Pine DOT GSO DOT 4 DOT 56 DOT 0404201434290 DOT 4141 AT slinky DOT cs DOT nyu DOT edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39

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 AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT 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/