[Patch] Avoid duplicate names in /proc/registry (which may crash find)
Fri Dec 5 09:57:00 GMT 2008
On Dec 4 21:49, Christian Franke wrote:
> Here is a simple approach to handle the duplicate key/value name problem in
> /proc/registry. A value is skipped if key with same name exists. Number of
> actual key existence checks are reduced by a simple hash table.
> The patch also adds dirent.d_type support, find does no longer crash.
> 2008-12-04 Christian Franke <email@example.com>
> * fhandler_registry.cc (__DIR_hash): New class.
> (d_hash): New macro.
> (key_exists): New function.
> (fhandler_registry::readdir): Allocate __DIR_hash.
> Record key names in hash table. Skip value if key
> with same name exists. Fix error handling of
> encode_regname (). Set dirent.d_type.
> (fhandler_registry::closedir): Delete __DIR_hash.
That looks like a quite neat idea to rectify this problem but, now that
I think of it I'm wondering if this isn't a good starting point for
a better solution as you proposed on the Cygwin list.
So let's assume there's a key and a value with the same name.
The old implementation just ignored the problem. Trying to access the
value failed because the value was simply shadowed by the key. `cat
foo' returned "is a directory" or something.
The now proposed solution hides the value instead. There just isn't a
value of that name anymore. In the end, the result is the same.
Accessing the value still doesn't work.
However, since these value were never accessible, doesn't that mean
there is no backward compatibility problem if we actually change the
name of the values instead to, say, foo.val? That's what you proposed
on the main list, right?
Is the above line of thought correct? If yes, together with your hash
table it would be quite simle to implement this. We would just have to
think of a good value for ".val". Unfortunately, there's no character
disallowed in the registry names, not even a \0 :(
Maybe ".val" is already a good suffix?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-patches