Mail Archives: cygwin/2004/04/22/13:27:49
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/
- Raw text -