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: findutils still broken

>   Ah.  No, you absolutely shouldn't say it "crashes", because it does not
> "crash".  Misdescribing a bug is the slowest imaginable way of getting it
> fixed!
>   Particularly so in this case, because I don't see why find *shouldn't*
> return an exit code of 1 when it's had all those errors.  Have you read "man
> find"?
>        find exits with status 0 if  all  files  are  processed
> successfully,
>        greater than 0 if errors occur.
>   Presumably the reason that this behaviour is new is that there used to be
> a bug that stopped it even attempting to recurse those dirs, because nothing
> with '*' in it could ever be a valid filename.

Contrary to your statement, /proc/registry/HKEY_CLASSES_ROOT/*/ is a valid directory name (but you sure have to be careful with shell quoting to actually get there).  My first guess is that there might be some bug in the readdir() implementation for the /proc filesystem.  Also, I've noticed that some cygwin syscalls are sloppy, and change errno to EISDIR even when they are successful.   POSIX allows implementations to have this sloppy behavior (change errno even on success) unless explicitly stated otherwise (although I think it should be discouraged), so a portable application must assume that errno is invalid for reading unless either a) the syscall gave indication that an error occurred and errno is valid (by returning -1 or some other known indication) or b) the application set errno before the syscall, and the syscall is documented as not changing errno except on error.  readdir() is documented as not changing errno except on error when the return value is NULL, but is allowed to change errno when the return value is non-NULL.  So, either cygwin's /proc filesystem is falling afoul of POSIX requirements on readdir(), or find is non-portable and is wrongly assuming that an errno changed to EISDIR even on a non-NULL return from readdir() means an error occurred.  I still don't know if the error is in find(1) or in cygwin1.dll, but don't have time to research further at the moment.

I also noticed while trying to pin down a more exact cause of the bug that strace behaves oddly when your current working directory is in /proc or any other virtual file system.  On further thought, it wasn't entirely unexpected: because strace is a windows only program, it assumes that the most recent Windows current directory is correct, because it has no way to know what the cygwin current directory should be.  However, this makes it very hard to try and figure out why find is failing, when bash thinks my cwd is inside of /proc/registry but strace does not.  So it would be awesome if strace could be patched to tell its cygwin children what the correct current working directory should be.

$ cd /tmp
$ cd /cygdrive
$ /bin/pwd
$ strace /bin/pwd |grep cwdstuff
   62    9680 [main] pwd 440 cwdstuff::get: posix /tmp
   93    9773 [main] pwd 440 cwdstuff::get: (/tmp) = cwdstuff::get (0x22EC40, 260, 1, 0), errno 0
  363   63369 [main] pwd 440 cwdstuff::get: posix /tmp
  118   63487 [main] pwd 440 cwdstuff::get: (/tmp) = cwdstuff::get (0x100A01C0, -1, 1, 1), errno 0

One parting thought - maybe cygwin is correct and find is buggy, considering that ls(1) has no problems recursing in /proc/registry, and it uses readdir() as well:

$ cd /proc/registry/HKEY_CLASSES_ROOT/\*
$ ls -R
AlwaysShowExt  InfoTip  shellex

ContextMenuHandlers  PropertySheetHandlers

ClearCaseMenu  Offline Files  Open With EncryptionMenu
LDVPMenu       Open With      PowerArchiver



./shellex/ContextMenuHandlers/Offline Files:

./shellex/ContextMenuHandlers/Open With:

./shellex/ContextMenuHandlers/Open With EncryptionMenu:


ClearCasePage                           {3EA48300-8CF6-101B-84FB-666CCB9BCD32}
CryptoSignMenu                          {883373C3-BF89-11D1-BE35-080036B11A03}






Eric Blake

Unsubscribe info:
Problem reports:

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