This is the mail archive of the cygwin@sources.redhat.com 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]

Re: [ANNOUNCEMENT]: Important change to symbolic link functionality


> I want to announce a change to the symlink functionality of Cygwin
> which introduces an incompatibility when trying to revert to older
> versions of the Cygwin DLL.
> [etc]

Great news? This has the potential to fix an irritating problem that I have
attributed to the current symlink functionality (see below).

> The new version can still read [the old] style of links but it creates
> a new style which is compatible to symlinks created by U/WIN.

Will it be possible to turn off the new version's support for old-style
symlinks< e.g. via an entry in the CYGWIN environment variable? I hope so.

> I would be glad about testers. Expect errors! However, I'm already
> using that DLL on my systems as well so it can't be too bad ;-)

I hereby volunteer.

Those who are not interested in the following somewhat lengthy description
of the "problem" I referred to above are advised to stop reading here.

I work on a Cray T3E which has a "data migration facility" (DMF), i.e. an
area of the file system where a directory entry can represent a file that is
either on a hard disk or on a tape-robot system. (I think this is often
called "hierarchical storage management".) If you try to read data from a
file that has been migrated to tape, then it takes approx 2 minutes to
retrieve the tape and copy the file back onto the disk.

I connect to this system from my PC (until recently running NT, now Win2000)
via a Samba share and I tend to interact with the files via Windows
software: file manager, editor, etc. (I hate to admit it but I like the
Windows GUI.)  If you use a set-up like this you may be surprised by the
frequency with which Windows likes to access data from its files! Every time
such an access is initiated on a file that has been migrated to tape, the
GUI tends to freeze for a couple of minutes. For example, if Windows
Explorer suspects there may be an icon inside a file it will read the file
so it can display it. Right-clicking on a file seems to initiate the reading
of data from the file too. The one-click mode for Windows 2000 is even
worse: if you just hover the mouse over a file it tries to read something
from it (looking for a SummaryInfo block I believe).

OK, so I can avoid this by using Cygwin, right? Well no. Doing a "ls" on a
directory with migrated files is OK, doing an "ls -l" takes several minutes,
I think because ls tries to read data from every file to see if is a
symlink. Command completion also seems to involve looking up symlinks, so is
unusable.

If Cygwin were to do its symlink checks only on files with the .lnk
extension, then these problems would go away.

It has been on the back of my mind for a while that symlinks are supposed to
have their system bit set. As far as I can tell, none of the files on the
DMF area, as served by Samba, does have its system bit set. So "ls -l"
shouldn't be looking inside any of the files to see if they're symlinks.
Perhaps there's some other reason to look inside the file? Oh well, I guess
that's one of life's little mysteries I'll never solve. But the new symlink
functionality sounds like a good idea anyway.

---
Mark Hadfield
m.hadfield@niwa.cri.nz  http://katipo.niwa.cri.nz/~hadfield
National Institute for Water and Atmospheric Research


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


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