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.


On Wed, 21 Apr 2004 13:16:03 -0400 (EDT), Igor Pechtchanski wrote:

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

So, what? U/Win employs such directory for this purpose, why Cygwin
should not? 
And I offer shortcuts instead of 0-byte files of U/Win. This provides
at least some clue to user outside of the emulation.

>Another potential problem is that the file being hard-linked may be
>opened, and thus you'll be unable to move it...

And, copying is not guaranteed to succeed in that case either.

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

All hard linking files have to produce the same i-node. 
So, hash-based i-node values won't work, the name of the hard linked
file will be presented by Cygwin instead. 
This is not an addition, but a branch in i-node calculation.

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

I'm not in a pipe dream to see all this happening without changes.
OTOH, this is more about adding code, rather than changing it, so the
end-result should be additional functionality, not a trade-off in
overall Cygwin performance for sth new.


>> I'm thinking of keeping link counts in that hidden directory.
>
>...as part of the filename, perhaps, just like the inode?
>

My initial idea was to keep count as filename extension, so the
filename would be [i-node].[count]
But then, this would practically render shortcuts useless; i.e. if the
file had a .txt extension, the user would no longer be able to open it
with a click on the shortcut.
Now, I think of keeping the extension as it is, and store link counts
in a subdirectory. Ideas, suggestions are welcome...

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

This is not going to be much different than how Cygwin currently
handles symlinks. I suggest you check out the relevant code before
further remarking on this.

regards,

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


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