This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
/proc/registry write access
- From: Christian Franke <Christian dot Franke at t-online dot de>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 29 Mar 2006 20:54:35 +0200
- Subject: /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