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: Bug in 'find' 4.2.11-CVS when traversing NTFS mount points

--- Corinna Vinschen wrote:

> On Feb 17 01:52, Tim Hubberstey wrote:
> > I'm experiencing a problem with 'find' when mounted NTFS volumes
> > (junctions) are involved. I have created a sample directory
> structure
> > /cygdrive/c/aa/aa where 'aa' is the mount point for another NTFS
> drive.
> > 
> > 
> > >From DOSland it looks like this:
> > C:\> dir \aa
> >  Directory of C:\aa
> > 2005/02/17  00:35       <DIR>          .
> > 2005/02/17  00:35       <DIR>          ..
> > 2005/02/17  00:35       <JUNCTION>     aa
> > 
> > The problem behavior with find is that these command works:
> > 
> > $ find /cygdrive/c/aa -name @@@F\*
> > /cygdrive/c/aa/aa/@@@FindMeFirst
> > $ find /cygdrive/c/aa/aa -name @@@F\*
> > /cygdrive/c/aa/aa/@@@FindMeFirst
> > 
> > but this gets errors and @@@FindMeFirst is not found:
> > 
> > $ find /cygdrive/c -name @@@F\*
> > find: Filesystem loop detected; `/cygdrive/c/aa/aa' has the same
> device
> > number and inode as a directory which is 2 levels higher in the
> > filesystem hierarchy.
> > 
> > I tried with CYGWIN=smbntsec and CYGWIN unset and the behavior was
> the
> > same. Volumes mounted on a root folder (e.g. C:\mnt) get the same
> error
> > except for "...which is 1 level higher...".
> The reason for your problem is that Cygwin doesn't check for volume
> mount
> points.  FWICT, there's a very simple solution for that, calling a
> specific
> Windows function (GetVolumePathName) from inside Cygwin.
> But I'm sure you don't want that.  Using this function inside of
> Cygwin
> slows down Cygwin incredibly, because that function is staggeringly
> slow.
> I called find in medium sized directory trees and find needed about
> 10
> times longer to traverse the directory tree than without this
> function.
> Sorry, but there's currently no good solution for that.

OK, how about this:

Find functions as it does now unless it encounters a "Filesystem loop".
If it finds a loop, it calls 'GetVolumePathName' to determine if the
cause is a junction and then does what's necessary to deal with it.
This way there is no speed penalty unless you have junctions.
Or, if that's not feasible, how about about this (slightly hacky)

1. Create a script that determines if there are any junctions in the
currently mounted trees and stores this information in the mount table
in some fashion. 

2. During installation, have setup offer a selection for whether or not
to search for junctions. If selected, run as a post-install script. The
script could also be available for the user to run if changes are made
in the junctions after installation.

If nothing else, maybe the detection of the loop could cause a further
check so the message could be changed to something more user-friendly
like "Warning: 'find' will not traverse junctions".


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

Unsubscribe info:
Problem reports:

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