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: Wed, 21 Apr 2004 13:16:03 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: "A. Alper Atici" <alperatici AT ttnet DOT net DOT tr>
cc: cygwin AT cygwin DOT com
Subject: Re: Emulating hard links on FAT et al.
In-Reply-To: <c64s42$red$1@sea.gmane.org>
Message-ID: <Pine.GSO.4.56.0404211210110.23681@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> <Pine DOT GSO DOT 4 DOT 56 DOT 0404201459540 DOT 4141 AT slinky DOT cs DOT nyu DOT edu> <00f001c4270e$5db365c0$66fda287 AT docbill002> <Pine DOT GSO DOT 4 DOT 56 DOT 0404201538541 DOT 4141 AT slinky DOT cs DOT nyu DOT edu> <c64s42$red$1 AT sea DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39

On Wed, 21 Apr 2004, A. Alper Atici wrote:

> {Too bad you guys are all top-posting. I hope I don't have to go
> through moving chunks of text again.}

Hey, I prefer to bottom-post myself, but when I come up against a
top-posted message, I'm usually too lazy to move stuff around, so I
"conform"... :-)

> Comments are inlined:
>
> >> > On Tue, 20 Apr 2004, Igor Pechtchanski wrote:
> >> > > 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.
>
> I plan to move all those files to a hidden dot-prefixed directory in
> root of the current drive/volume. Emulated POSIX API need to conceal
> that directory only.

Note that this directory will be visible at the host OS (Windows) level.
Another potential problem is that the file being hard-linked may be
opened, and thus you'll be unable to move it...

> The internal name I consider is the i-node value calculated before move,
> which will also be used to return i-node for the files hard linking to
> it.

So the inode computation code (in stat()) will need to be changed.

> >> > > 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.
>
> As I've noted, i-node won't have to be computed every time.

Well, it'll now have to be derived from the filename *in addition to* the
current computation code.  This introduces another clause into the
computation, and makes all calls to stat() slower.

> I don't presume changes to open() et al. AFAICS, path_conv::check()
> needs to be addressed (need some feedback on this, however).

Sure, but path_conv::check() is called from open(), so in effect, you are
changing the code...

> >> > 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.
>
> ntea relies on a set of win32 functions available to NT family only.

Yes, but as I asked -- is that necessary?  I mean, if it will require a
full rewrite of the ntea functionality, then NT is certainly a
prerequisite.

> I'm primarily concerned with hard link functionality on 9x/ME systems,
> so it won't work.
> I'm thinking of keeping link counts in that hidden directory.

...as part of the filename, perhaps, just like the inode?

> >On Tue, 20 Apr 2004, Bill C. Riemers wrote:
> >>   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.
>
> Right.
> And, I didn't say I was thinking of emulating symbolic links.
>
> >> 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
>
> I'm NOT talking about symlinks.

You're talking about (a special kind of) shortcuts.  So was I.  Sorry if I
was unclear.  The above still stands (modulo 's/symlink/shortcut/g').

> This is about hard links, emulated using a new type of shortcut.
> Symlinks are also EMULATED with a special shortcut in Cygwin.
>
>
> On Tue, 20 Apr 2004 15:47:09 -0400 (EDT), Igor Pechtchanski wrote:
>
> >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
>
> The reason I insist on shortcuts is to alleviate these issues.

Unfortunately, shortcuts aren't necessarily equivalent to the actual
files.  I have to check with MSDN, but some system calls are not going to
respect shortcuts, and will present problems no matter what approach you
take.

> >altogether, and copying the files *is* the best approximation.
>
> It should not be an approximation from Cygwin's point of view.
> And, I think it will be a better approximation for Windows since
> single copy of a file exists.

As long as you can make it transparent -- sure.  As I said, though: I
think it'll be hard.

> I'm mostly concerned about atomicity and synchronization issues,
> especially during initial link and final unlink.
> --
> A. Alper Atici

Yep, that's one of the things that'll make it hard.  Good luck!
	Igor
-- 
				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/