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
To: cygwin AT cygwin DOT com
From: "A. Alper Atici" <alperatici AT ttnet DOT net DOT tr>
Subject: Re: Emulating hard links on FAT et al.
Date: Thu, 22 Apr 2004 20:27:58 +0300
Lines: 74
Message-ID: <c68v9k$fp1$1@sea.gmane.org>
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> <Pine DOT GSO DOT 4 DOT 56 DOT 0404211210110 DOT 23681 AT slinky DOT cs DOT nyu DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet AT sea DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: mstr195175-13880.dial-in.ttnet.net.tr
X-Archive: encrypt
User-Agent: Forte Agent 2.0/32.646

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/