Avoid duplicate names in /proc/registry (which may crash find) ?
Tue Dec 2 14:32:00 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
According to Corinna Vinschen on 12/2/2008 5:08 AM:
> - If find crashes in this situation, isn't this a bug in find which
> should be fixed in find?
No. The problem is that readdir() is returning the same name twice, once
for a directory and once for a file. Even without d_type support, this
means when you go to stat() that name, you get the same answer twice
(assuming that stat visits the first of the two instances), where the
second answer is wrong; even without d_type, find is unable to traverse
the second of the two identical names. In other words, the problem is not
in find, but in the fact that Windows allows the registry to violate
filesystem semantics by giving the same name to distinct contents.
> - /proc/registry is a convenience for reading the registry. Due to some
> funny definitions of the registry it's not a full solution. You can't
> write this way, you can't even access the "(Default)" key values.
> I personally don't worry if some border cases don't work. For the
> border cases and for the full access we have regtool.
Maybe the solution for this problem is to make the registry always
populate d_type with DT_UNKNOWN; the readdir will still list the name
twice, but at least with the same d_type, and such that find falls back to
a stat(), which sees the info on the first entry twice, no worse than it
If you do go with a workaround, using a full-blown set<> or hash-table in
option 2 seems like overkill. When enumerating a parent key, the code
currently visits all sub-keys first, then all values. Isn't it simply a
matter of checking, for each sub-key, whether a value of the same name
exists, in which case you could then munge the sub-key as name\ or
name%5c? (I'm going with the backslash as the munging character, to make
it obvious that this was the sub-key).
Don't work too hard, make some time for fun as well!
Eric Blake email@example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin