Mail Archives: cygwin/2004/04/21/00:09:58
{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/
- Raw text -