/proc/registry write access

Christian Franke Christian.Franke@t-online.de
Thu Mar 30 18:40:00 GMT 2006


Igor Peshansky wrote:
> On Wed, 29 Mar 2006, Christian Franke wrote:
>
>   
>> [snip]
>> A) Add a type suffix to value name if a new value is created.
>> For existing values, the suffix is optional and must be correct if present.
>>
>> The suffix separator should be rarely used in registry value names and
>> allowed for windows filenames.
>> Therefore ':' cannot be used, I would suggest ','.
>>     
>
> One question at this point: why do you think it has to be allowed in
> Windows filenames?  This is going to be used as a separator for the
> metadata that was not present before.  There will be no physical
> manifestation of these filenames on the disk.  So why does it need to be
> restricted to valid Windows filename characters?
>   


You're right, ':' would also work for commands like:

$ echo "String" > /proc/registry/subkey/value:sz

But copying to filesystem using standard commands would not work:

$ cp /proc/registry/subkey/* /path/subdir


BTW: Cygwin simply discards everything following ':' in a path

$ touch 'foo:bar'
$ ls
foo

Bug or feature?-)


>   
>> Open question: Allow type change by renaming?
>>     
>
> Here's another one: mapping inherently multi-value types into file write
> operation.  IOW, how would you write a value of type REG_MULTI_SZ?  By
> forcing a separator (NUL?)?  By writing multiple strings using the append
> function (i.e., "echo 'a' > val; echo 'b' >> val")?
>   

Forcing trailing \0 and convert \n to \0 possibly makes sense for 
REG_MULTI_SZ.

But the data should not depend on write chunks.
The result of:
$ echo -n foo > val; echo -n bar >> val
should be the same as:
$ echo -n foobar > val


> We could make the type modifier optional (omitting it would default to the
> current type for existing values and to, say, REG_SZ for new values).
> Also, it might make sense to allow type change if O_TRUNC is set on open,
> and disallow it otherwise...
>   

Yes, that makes sense, because changing type with existing data may lead 
to invalid data.
It is also ambiguous in some situations, i.e
On SZ to BIN type change, should data be converted to ASCII or kept as 
Unicode?

This leads to the next question: Use UTF8 on REG_SZ?


>   
>> Using the separator in value names could be handled if it is encoded
>> somehow, e.g: "foo%2cbar,sz".
>> This would also be useful for current read access for value name
>> containing slashes.
>>     
>
> An orthogonal issue.  We may simply need to fix the "open" implementation
> to be more precise in determining the key/value boundary, rather than
> assuming the value starts at the last '/'.
>   

Some heuristics should work for most situations, but may also lead to 
ambiguities:

$ echo "String" > /proc/registry/subkey/text/html

Subkey ".../text", value "html" or value "text/html" ?

Backslashes are another issue:

$ ls /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices/
\DosDevices\A:
...

Some encoding for '/', '\', ':' would solve these.


>   
>> B) Same as above, but expose types in directory listing:
>>
>> $ ls /proc/registry/subkey
>> sz_value,sz
>> dword_value,dword
>>     
>
> Here's YA alternative: a special pseudo-file that maps filenames to types.
> 	Igor
>   

Like TRANS.TBL in ISO-FS on RR-CDs?
Yes, IMO really an alternative to consider.
With such a pseudo file the type can be stored using

$ cp /proc/registry/subkey/* /path/subdir

but restoring is (at least) difficult.



Turns out to be rather complex...
Now I know why I still prefer plain ASCII files in /etc/ directory to 
ugly registry database...;-)

Christian



More information about the Cygwin-developers mailing list