findutils vs. /proc/registry

[Eric Blake <ebb9 at byu dot net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A while ago there was a thread that complained that 'find /proc/registry'
did not work.  I've done some debugging, and found more details.  Also,
the upstream maintainer has added a patch to use gnulib fts() instead of
his own directory traversal code on CVS, which improves, but doesn't fix,
the behavior.

To begin with, the current version of find is failing to recurse into
registry directories:

$ cd /proc/registry/HKEY_CLASSES_ROOT/\*/shellex/ContextMenuHandlers
$ find .
.
./Offline Files
find: ./Offline Files: Is a directory
./Open With
find: ./Open With: Is a directory
./Open With EncryptionMenu
find: ./Open With EncryptionMenu: Is a directory
./{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}
find: ./{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}: Is a directory

I traced this to the fact that findutils() expects open(".", O_RDONLY) to
succeed if a directory is readable (and that is my reading of POSIX as
well), but cygwin is failing with EISDIR.  Is there any way cygwin can be
patched to allow open(".", O_RDONLY) to succeed?

With CVS findutils, the new fts() code uses opendir() instead of open() to
save state on which directory is being traversed, and this lets find
finally browse into subdirectories.  But now the behavior is different
depending on whether the current working directory is in /proc/registry or
not:

$ ~/findutils/find/find "`pwd`"
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files
/home/eblake/findutils/find/find:
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline
Files/@: No such file or directory
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With
/home/eblake/findutils/find/find:
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open
With/@: No such file or directory
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With
EncryptionMenu
/home/eblake/findutils/find/find:
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With
EncryptionMenu/@: No such file or directory
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/{a2a9545d-a0c2-42
b4-9708-a0b2badd77c8}
/home/eblake/findutils/find/find:
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}/@:
No such file or directory

$ cd
$ ~/findutils/find/find "$OLDPWD"
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files
/proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files/@

Hmm, when started from within /proc/registry, find sees every file, but
reports an error that leaf nodes are returning ENOENT.  But when started
from elsewhere, find is able to report on the leaf nodes without error,
but only traverses the first directory instead of the entire tree.

And that's where where I got stuck debugging.  Since /proc/registry is
virtual, the notion of current working directory being a virtual directory
is lost as soon as gdb or strace is used (reverting to pwd of the last
non-virtual directory), so under gdb, I'm always seeing the second
behavior.  I have no idea whether the bug exposed by the CVS find is in
find, or in cygwin, but it is sure annoying that there are two behaviors,
and that only one of those behaviors is visible from gdb and strace.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC91GD84KuGfSFAYARAtg2AJ9y0hRIuoCQlRd1gMQRTeUjo8uJTQCfZR0f
AtxUt1B/wEACAw1yrddIbtc=
=Yvfn
-----END PGP SIGNATURE-----

--
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/