Emulating hard links on FAT et al.

[A. Alper Atici]

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

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

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


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

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

I'm mostly concerned about atomicity and synchronization issues,
especially during initial link and final unlink.


--
A. Alper Atici               OpenPGP KeyID: 0xB824F550


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