/proc/registry write access

[Christian Franke]

Hi all,

on Mar 3, Corinna Vinschen wrote (in cygwin-patches@cygwin.com):

> Btw., since you seem to be interested in hacking the registry...  would
> you also be interested to introduce registry write access below
> /proc/registry inside of the Cygwin DLL?  That would be extra cool.
> I'm not quite sure how to handle the mapping from file types to
> registry key types, but there might be some simple way which I'm just
> too blind to see.
>
>   

Some quotes to restart the discussion:


Dave Korn wrote:
>   Hey, how about using pseudo filename-extensions on the pseudo-files that
> represent registry keys?
>
>   i.e
>
> $  echo "Foo" >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.sz
> creates /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName, type
> REG_SZ, content "Foo<NUL>"
>
> $  echo "%WINDIR%"
>   
>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.xsz
>>     
> creates /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName as
> REG_EXPAND_SZ
>
> $  echo "23"
>   
>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.dword
>>     
> $  echo "0x17"
>   
>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.dword
>>     
>
> $  dd bs=1024 count=3 if=/dev/random
> of=/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.bin
>
> $  touch /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.none
>
> etc etc ?  (We might even want a $CYGWIN option to make the extension show up
> in dir listings, but it wouldn't be backwardly-compatible to do so in
> general).
>
>   Hmm, and how about for MULTI_SZ taking account of the open mode?
>
> $ echo "String1"
>   
>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz
>>     
> $ echo "String2"
>   
>>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz
>>>       
> $ echo "String3"
>   
>>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz
>>>       
> $ echo "String4"
>   
>>> /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz
>>>       
> $ od -c < /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz
>   String1\0String2\0String3\0String4\0\0
>
>
>     cheers,
>       DaveK
>   


Corinna Vinschen wrote:
> On Mar  3 13:12, Dave Korn wrote:
>   
> [above]
> That's actually an interesting idea.  I was always thinking along
> the lines of using POSIX file types (plain,socket,pipe,...).
>
> However, file suffixes is something we're already suffering from
> a lot (it's not by chance that SUFFix and SUFFer are so similar, IMHO).
>
> What if a key "foo.sz" really exists and somebody wants to create
> a registry key "foo"?  When reading "foo", which file is meant?
> What's the order of checking suffixes?
>
> When somebody writes to a key "foo", what's the default suffix,
> er..., key type?  Or does that fail with an error message?
>
>
> Corinna
>
>   

Igor Peshansky wrote:
> Now, what if you write a file as foo.sz, and then write it as foo.dw.  Do
> we change the key type?  Do we fail with ENOENT?  What is the semantics
> there?
>
> Also, this suffix idea reminds me more of versions on VMS or streams on
> NT, rather than real extensions.  I wonder if we could/should use "foo:dw"
> or "foo:sz", rather than using the extension...  IOW, "foo.sz" might be a
> valid filename, but "foo:sz" already cannot be on certain filesystems...
> The question about using two different filetypes in a row still applies,
> though.
> 	Igor
>   


Igor Peshansky wrote:
> That still might not be a bad approach -- maybe introduce extra,
> registry-specific, flags for open() that reflect the file (i.e, key) type,
> and then implement writes to the files based on those flags...  Just
> another alternative to consider...
> 	Igor
>   


Here is a brief summary of 4 possible alternatives A-D to handle the 
type issue:

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 ','.

$ ls /proc/registry/subkey
sz_value
dword_value

$ cat /proc/registry/subkey/sz_value
String

$ cat /proc/registry/subkey/sz_value,sz
String

$ cat /proc/registry/subkey/sz_value,dword
/proc/registry/subkey/sz_value,dword: Access denied

$ echo "NewString" >/proc/registry/subkey/sz_value

$ echo "NewString" >/proc/registry/subkey/sz_value,sz

$ echo "NewString" >/proc/registry/subkey/sz_value,dword
/proc/registry/subkey/sz_value,dword: Access denied

$ echo "NewString" >/proc/registry/subkey/new_sz_value
/proc/registry/subkey/new_sz_value: Access denied

$ echo "NewString" >/proc/registry/subkey/new_sz_value,sz

Open question: Allow type change by renaming?

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.


B) Same as above, but expose types in directory listing:

$ ls /proc/registry/subkey
sz_value,sz
dword_value,dword

...


C) Add a type prefix to value data.

$ ls /proc/registry/subkey
sz_value
dword_value

$ cat /proc/registry/subkey/sz_value
sz:String

$ echo "NewString" >/proc/registry/subkey/sz_value
/proc/registry/subkey/new_sz_value: Access denied

$ echo "sz:NewString" >/proc/registry/subkey/sz_value

$ echo "sz:NewString" >/proc/registry/subkey/new_sz_value

This may be difficult to implement, because the registry value cannot be 
created until the type prefix has been read.


D) Use special open/stat flags to set/query the type.

e.g.:
open("/proc/registry/subkey/new_sz_value", O_WRONLY|O_CREAT|O_REG_SZ, 0666)



Comparing the above with this small wishlist for /proc/registry write 
access:

1.) There should be no need for extra tools.

2.) Read access should be backward compatible.

3.) Copy between registry and filesystem should be possible, e.g.:
$ cp -r /proc/registry/subkey /path/subtree
$ tar -x -f /path/regsave.tar -C /proc/registry/subkey


we get:

Pr./Alt.: A   B   C   D
1.       Yes Yes Yes  No
2.       Yes  No  No Yes
3.        No Yes Yes  No


I would prefer B), but in a new filesystem /proc/registry-rw to keep 
/proc/registry backward compatible.

Thanks for any comment.

Christian