Mail Archives: cygwin/2004/04/21/13:18:46
On Wed, 21 Apr 2004, A. Alper Atici wrote:
> {Too bad you guys are all top-posting. I hope I don't have to go
> through moving chunks of text again.}
Hey, I prefer to bottom-post myself, but when I come up against a
top-posted message, I'm usually too lazy to move stuff around, so I
"conform"... :-)
> 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.
Note that this directory will be visible at the host OS (Windows) level.
Another potential problem is that the file being hard-linked may be
opened, and thus you'll be unable to move it...
> 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.
So the inode computation code (in stat()) will need to be changed.
> >> > > 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.
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.
> 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...
> >> > 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.
Yes, but as I asked -- is that necessary? I mean, if it will require a
full rewrite of the ntea functionality, then NT is certainly a
prerequisite.
> 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.
...as part of the filename, perhaps, just like the inode?
> >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.
You're talking about (a special kind of) shortcuts. So was I. Sorry if I
was unclear. The above still stands (modulo 's/symlink/shortcut/g').
> 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.
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.
> >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.
As long as you can make it transparent -- sure. As I said, though: I
think it'll be hard.
> I'm mostly concerned about atomicity and synchronization issues,
> especially during initial link and final unlink.
> --
> A. Alper Atici
Yep, that's one of the things that'll make it hard. Good luck!
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
--
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 -