This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

/proc/registry write access


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]