This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: /proc/registry write access
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