interesting problem with "find"

interesting problem with "find"

[Alan]

One of my collegues just found an interesting behavior in "find". We are running 
cywin32 b18, cygwin.dll is Sergey's latest, and the find that comes with it on 
NT4.0. 

He has found that if you have nested directories of the same name eg) x/x/... or 
even x/y/x/... and type "find . -name '*' -print", nothing is found except the 
directories. Renaming the top level directory to anything else or specifying the 
top directory rather than using "." "fixes" the problem. However, the results 
are somewhat contradictory. Could someone explain the following series of 
results? (all within the b18 bash shell):

We start with a directory tree containing only:
x/y/x/zz.tmp then:

1) find . -name * -print
./x
./x/y/x
bash is globbing *->x and looking for that as expected, finding the 2 
directories.

2) find . -name "*" -print
./x
./x/y
./x/y/x
This should work, globbing is escaped. But it finds only the directories, not 
the file. Single or double quotes or backslash have the same behavior.

3) find . -name *.tmp -print
finds nothing: globbing again, can't find "x.tmp"

4) find . -name "*.tmp" -print
finds nothing. This should work.

Substituting "x" for "." in the four cases:

1) find x -name * -print
x
x/y/x
Get the expected result, looking for "x"

2) find x -name "*" -print
x
x/y
x/y/x
x/y/x/zz.tmp
This is what it should be. Why didn't it work with "."?

3) find x -name *.tmp -print
x/y/x/zz.tmp
I would have thought that this would fail. It should be looking for "x.tmp" or 
maybe "y.tmp" depending on which directory it's globbing in.

4) find x -name "*.tmp" -print
x/y/x/zz.tmp
This is as expected.

Renaming either of the "x" directories to z so that we have, for example:
z/y/x/zz.tmp (same result with x/y/z/zz.tmp)
1) find . -name * -print
./z
as expected after globbing.

2) and 4) give the results you'd expect, they find either all files or only the 
.tmp file since the "*" is escaped.

3) however works just like 4), as if the "*" were escaped.

Alan
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: interesting problem with "find"

[Bartlee A. Anderson]

I've noticed a similar problem with rm.
In directories with structure something/yada/yada/other/...
rm -rf will tell you that you have a circular directory structure and to
notify your administrator, it is almost certainly corrupt.
You have to remove from the second yada and then once it's gone, the
original command will work. Yuck.

Alan Jonckheere at Fermi National Accelerator Lab wrote:
> 
> One of my collegues just found an interesting behavior in "find". We are running
> cywin32 b18, cygwin.dll is Sergey's latest, and the find that comes with it on
> NT4.0.
> 
> He has found that if you have nested directories of the same name eg) x/x/... or
> even x/y/x/... and type "find . -name '*' -print", nothing is found except the
> directories. Renaming the top level directory to anything else or specifying the
> top directory rather than using "." "fixes" the problem. However, the results
> are somewhat contradictory. Could someone explain the following series of
> results? (all within the b18 bash shell):
> 
> We start with a directory tree containing only:
> x/y/x/zz.tmp then:
> 
> 1) find . -name * -print
> ./x
> ./x/y/x
> bash is globbing *->x and looking for that as expected, finding the 2
> directories.
> 
> 2) find . -name "*" -print
> ./x
> ./x/y
> ./x/y/x
> This should work, globbing is escaped. But it finds only the directories, not
> the file. Single or double quotes or backslash have the same behavior.
> 
> 3) find . -name *.tmp -print
> finds nothing: globbing again, can't find "x.tmp"
> 
> 4) find . -name "*.tmp" -print
> finds nothing. This should work.
> 
> Substituting "x" for "." in the four cases:
> 
> 1) find x -name * -print
> x
> x/y/x
> Get the expected result, looking for "x"
> 
> 2) find x -name "*" -print
> x
> x/y
> x/y/x
> x/y/x/zz.tmp
> This is what it should be. Why didn't it work with "."?
> 
> 3) find x -name *.tmp -print
> x/y/x/zz.tmp
> I would have thought that this would fail. It should be looking for "x.tmp" or
> maybe "y.tmp" depending on which directory it's globbing in.
> 
> 4) find x -name "*.tmp" -print
> x/y/x/zz.tmp
> This is as expected.
> 
> Renaming either of the "x" directories to z so that we have, for example:
> z/y/x/zz.tmp (same result with x/y/z/zz.tmp)
> 1) find . -name * -print
> ./z
> as expected after globbing.
> 
> 2) and 4) give the results you'd expect, they find either all files or only the
> .tmp file since the "*" is escaped.
> 
> 3) however works just like 4), as if the "*" were escaped.
> 
> Alan
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".

-- 
Bartlee A. Anderson     |  Sys. Test (ISDN-Commands-Trans Link-Tools)
Rockwell International  |                Electronic Commerce Division
300 Bauman Ct.          |                    banders@ecd.rockwell.com
MS 933-605      Opinions my own, not Rockwell's  VOICE (630) 227-8975
Wood Dale, IL 60191     |                        FAX   (630) 227-9771
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: interesting problem with "find"

[Chris Faylor]

In article < 346874E8.571D@switch.rockwell.com >,
Bartlee A. Anderson <banders@ECD.Rockwell.COM> wrote:
>I've noticed a similar problem with rm.
>In directories with structure something/yada/yada/other/...
>rm -rf will tell you that you have a circular directory structure and to
>notify your administrator, it is almost certainly corrupt.
>You have to remove from the second yada and then once it's gone, the
>original command will work. Yuck.

I don't think that this is a problem with your directory.  More likely,
this is a problem with cygwin's calculation of inodes.  rm -rf keeps
track of the inodes of directories that it deletes.  If it comes across
a directory with the same inode as one it thinks that it has already deleted,
then it thinks something is wrong.

Since Windows does not support the concept of an inode, cygwin has to
create its own.  It bases the inode on the name of the file.  So, if you
have two directories with the same name, they'll have the same inode.
When rm -r sees these two (different) directories with the same inode,
it complains.

Currently, the only workaround is to delete the lower level subdirectories
by hand.  Sorry.
-- 
http://www.bbc.com/	cgf@bbc.com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: interesting problem with "find"

[raf]

>Since Windows does not support the concept of an inode, cygwin has to
>create its own.  It bases the inode on the name of the file.  So, if you
>have two directories with the same name, they'll have the same inode.
>When rm -r sees these two (different) directories with the same inode,
>it complains.

>Currently, the only workaround is to delete the lower level subdirectories
>by hand.  Sorry.

or change the inode calculation to be based
on the full path rather than the filename.

raf

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: interesting problem with "find"

[Geoffrey Noer]

Larry Hall wrote:
[...]
> The problem with rm is because the algorithm cygwin32 has for generating
> inode numbers does not guarantee unique values.  In the UNIX world, these
> values must be unique.  If they aren't, it indicates the file system is 
> corrupt.  This is why this message occurs for rm.  An explanation of this
> should be in the FAQ by now.
[...]

Added it.  Fixing the inode spoofing is definitely on my list of things
to fix...

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: interesting problem with "find"

[Fergus Henderson]

Larry Hall <lhall@rfk.com> writes:

>Bartlee A. Anderson wrote:
>>I've noticed a similar problem with rm.
>>In directories with structure something/yada/yada/other/...
>>rm -rf will tell you that you have a circular directory structure and to
>>notify your administrator, it is almost certainly corrupt.
>>You have to remove from the second yada and then once it's gone, the
>>original command will work. Yuck.
>
>The problem with rm is because the algorithm cygwin32 has for generating
>inode numbers does not guarantee unique values.  In the UNIX world, these
>values must be unique.  If they aren't, it indicates the file system is 
>corrupt.  This is why this message occurs for rm.  An explanation of this
>should be in the FAQ by now.
>
>This is NOT the same issue as the find problem.

Are you sure?  I think `find' might be confused by the non-unique inode
numbers, just as `rm' is.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: interesting problem with "find"

[Larry Hall (RFK Partners Inc)]

At 09:08 AM 11/11/97 -0600, Bartlee A. Anderson wrote:
>I've noticed a similar problem with rm.
>In directories with structure something/yada/yada/other/...
>rm -rf will tell you that you have a circular directory structure and to
>notify your administrator, it is almost certainly corrupt.
>You have to remove from the second yada and then once it's gone, the
>original command will work. Yuck.

The problem with rm is because the algorithm cygwin32 has for generating
inode numbers does not guarantee unique values.  In the UNIX world, these
values must be unique.  If they aren't, it indicates the file system is 
corrupt.  This is why this message occurs for rm.  An explanation of this
should be in the FAQ by now.

This is NOT the same issue as the find problem.

Larry Hall                      lhall@rfk.com
RFK Partners, Inc.              (781) 239-1053
8 Grove Street                  (781) 239-1655 - FAX
Wellesley, MA, 02181

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".