[Patch] regtool: Add load/unload commands and --binary option

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Igor Peshansky
On Fri, 3 Mar 2006, Corinna Vinschen wrote:

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

Hmm, there is currently no way for the programs to find out the registry
key type, unless we introduce new functionality into stat() or something.

As it is, why would the programs need to know the key type, anyway?  They
just write the data, and fhandler_registry takes care of converting it to
the right format (using arbirtary conventions of some sort).  The only
potential problems are REG_MULTI_SZ and REG_EXPAND_SZ (in the former case
it's a question of picking a string delimiter, and in the latter it's
about annotating expandable values).

Am I missing something?
        Igor
P.S. Thanks a lot to Christian for this cool functionality.
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
Reply | Threaded
Open this post in threaded view
|

RE: [Patch] regtool: Add load/unload commands and --binary option

Igor Peshansky
In reply to this post by Dave Korn
On Fri, 3 Mar 2006, Dave Korn wrote:

> > That's actually an interesting idea.  I was always thinking along
> > the lines of using POSIX file types (plain,socket,pipe,...).
> >
> > What if a key "foo.sz" really exists and somebody wants to create
> > a registry key "foo"?
>
>   No problem.  If you want to create foo, you write to "foo.sz".  If you
> want to create foo.sz, you have to write to "foo.sz.sz".  Unless of
> course foo.sz is a dword, in which case you'd write to "foo.sz.dw", etc
> etc.
>
> > When reading "foo", which file is meant?
>
>   There can only be one at a time, because in the registry there can
> only be one value with the name foo, regardless of what type it has.
>
> > What's the order of checking suffixes?
>
>   I'm proposing that the suffix is only used when creating or writing to
> the file, to determine the type, but the suffix is stripped off for
> generating the actual name, and is not shown in dir listings, and is not
> required to open the file for read.
>
> > When somebody writes to a key "foo", what's the default suffix, er...,
> > key type?  Or does that fail with an error message?
>
>   Either; I haven't a strong opinion on the matter.

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
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
Reply | Threaded
Open this post in threaded view
|

RE: [Patch] regtool: Add load/unload commands and --binary option

Dave Korn

> Now, what if you write a file as foo.sz, and then write it as foo.dw.  Do
> we change the key type?  

  Absolutely.

> Do we fail with ENOENT?  What is the semantics there?

  Well, the semantics of the registry API is that you specify the type
explicitly every time you set a value, and that doing so overrides the old
type in just the same way as setting the value overrides the old value.

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

  I don't think it would matter very much precisely how we do it; after all
it's a virtual FS and we can implement whatever standards we like.  

> IOW, "foo.sz" might be a
> valid filename, but "foo:sz" already cannot be on certain filesystems...

  Yes, but then again it's perfectly valid on others, including managed
mounts, and given that it's *not* a filename that could /never/ occur, it
doesn't really gain you any real separation of the namespaces.

> The question about using two different filetypes in a row still applies,
> though.

  Like I said, setting a value always sets the content and type at the same
time; same would apply in this case.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

RE: [Patch] regtool: Add load/unload commands and --binary option

Dave Korn
In reply to this post by Igor Peshansky
On 03 March 2006 16:02, Igor Peshansky wrote:


>> 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.
>
> Hmm, there is currently no way for the programs to find out the registry
> key type, unless we introduce new functionality into stat() or something.
>
> As it is, why would the programs need to know the key type, anyway?  

  Because they aren't writing it for their own benefit, but in order for it to
be read by some other app that requires it to be of a specific type.

> They
> just write the data, and fhandler_registry takes care of converting it to
> the right format (using arbirtary conventions of some sort).  The only
> potential problems are REG_MULTI_SZ and REG_EXPAND_SZ (in the former case
> it's a question of picking a string delimiter, and in the latter it's
> about annotating expandable values).
>
> Am I missing something?

  You're thinking of the registry as some place where a program puts its own
private data and reads it back and therefore assuming that it doesn't matter
what actually is /in/ the registry as long as the program gets back the exact
same stuff it put in there, but sometimes programs want to alter or set
registry values for external apps that require a specific type.  If cygwin
chose a type and didn't provide a way to specify, this feature would be of
much more limited use as you couldn't use it to modify an existing value
because cygwin might decide to write it back as a different type and break
whatever-it-was that depended on it.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Yitzchak Scott-Thoennes
In reply to this post by Dave Korn
On Fri, Mar 03, 2006 at 01:12:01PM -0000, Dave Korn wrote:

> On 03 March 2006 09:46, Corinna Vinschen wrote:
>
> >
> > 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.
>
>
>   Hey, how about using pseudo filename-extensions on the pseudo-files that
> represent registry keys?

As long as we are how-bouting, I'm looking at

http://search.cpan.org/~tyemq/Win32-TieRegistry-0.24/TieRegistry.pm

as another example of non-traditional access to the registry.  How
about /proc/registry//machinename/... to access the registry of other
computers on the network?  Or is // not at the beginning a no-no?
Reply | Threaded
Open this post in threaded view
|

RE: [Patch] regtool: Add load/unload commands and --binary option

Dave Korn
On 03 March 2006 17:42, Yitzchak Scott-Thoennes wrote:

>>   Hey, how about using pseudo filename-extensions on the pseudo-files that
>> represent registry keys?
>
> As long as we are how-bouting, I'm looking at
>
> http://search.cpan.org/~tyemq/Win32-TieRegistry-0.24/TieRegistry.pm
>
> as another example of non-traditional access to the registry.  How
> about /proc/registry//machinename/... to access the registry of other
> computers on the network?  Or is // not at the beginning a no-no?


  There may be POSIX-y issues with // anywhere else.

  And the idea of having /proc contain objects related to another machine
altogether does somewhat make my skin crawl.  If we wanna do this at all, I'd
rather it was done as //machine/registry/..., i.e. make a UNC share for the
registry virtual fs tree.... this I guess would require a cygwin MUP, which
isn't gonna happen any time soon though.

  Should we move this thread off the -patches list perhaps?

    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Christian Franke
In reply to this post by Corinna Vinschen-2
Corinna Vinschen wrote:
> I applied the patch.  

Thanks.

> I just had to reformat your ChangeLog slightly
> (a TAB before all lines, no extra indentation for lines which don't
> start with a '*').
>  
SeaMonkey expands tabs to spaces...
Will use attachment for ChangeLog next time.

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

In fact I had the idea to hack the registry, in particular fix the read
access to registry values starting with backslash:

$ cd /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices
$ ls
...
\DosDevices\C:
\DosDevices\D:
...
$ cat \\DosDevices\\C:
cat: \DosDevices\C:: No such file or directory

Using a URL-like "%XX" encoding for invalid characters (/\?%) may be the
right thing to do.

$ ls
...
%5cDosDevices%5cC:

I found that all standard ascii chars except ^ % ` are used in value names

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

Because POSIX has no notion about file types, the type has to be somehow
encoded into the name if a new key is created.
The major drawback of this approach is that the read path is different
from the write path.

I would suggest to add a second R/W view to the registry where both path
are identical.
A type extension should be added via a rarely used character:

$ ls /proc/registry/SUBKEY
reg_sz_value
reg_binary_value
reg_dword_value

$ ls /proc/registry-rw/SUBKEY
reg_sz_value,sz
reg_binary_value,bin
reg_dword_value,dword

Then you should have the ability to copy subkeys to file trees and vice
versa:
cp -r /dev/registry-rw/SUBKEY /tmp/SUBKEY
rm -r /dev/registry-rw/SUBKEY
cp -r /tmp/SUBKEY /dev/registry-rw/SUBKEY

Suggest to start a new thread for this discussion....

Christian

Reply | Threaded
Open this post in threaded view
|

RE: [Patch] regtool: Add load/unload commands and --binary option

Igor Peshansky
In reply to this post by Dave Korn
On Fri, 3 Mar 2006, Dave Korn wrote:

> On 03 March 2006 16:02, Igor Peshansky wrote:
>
> >> 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.
> >
> > Hmm, there is currently no way for the programs to find out the
> > registry key type, unless we introduce new functionality into stat()
> > or something.
> >
> > As it is, why would the programs need to know the key type, anyway?
>
>   Because they aren't writing it for their own benefit, but in order for
> it to be read by some other app that requires it to be of a specific
> type.
>
> > They just write the data, and fhandler_registry takes care of
> > converting it to the right format (using arbirtary conventions of some
> > sort).  The only potential problems are REG_MULTI_SZ and REG_EXPAND_SZ
> > (in the former case it's a question of picking a string delimiter, and
> > in the latter it's about annotating expandable values).
> >
> > Am I missing something?
>
>   You're thinking of the registry as some place where a program puts its
> own private data and reads it back and therefore assuming that it
> doesn't matter what actually is /in/ the registry as long as the program
> gets back the exact same stuff it put in there, but sometimes programs
> want to alter or set registry values for external apps that require a
> specific type.  If cygwin chose a type and didn't provide a way to
> specify, this feature would be of much more limited use as you couldn't
> use it to modify an existing value because cygwin might decide to write
> it back as a different type and break whatever-it-was that depended on
> it.

Actually, I did think of registry as shared data, but I also assumed that
the creation of value files would be separate from writing to them, and
that the actual writing would not change the type.

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
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Igor Peshansky
In reply to this post by Christian Franke
On Fri, 3 Mar 2006, Christian Franke wrote:

> In fact I had the idea to hack the registry, in particular fix the read
> access to registry values starting with backslash:
>
> $ cd /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices
> $ ls
> ...
> \DosDevices\C:
> \DosDevices\D:
> ...
> $ cat \\DosDevices\\C:
> cat: \DosDevices\C:: No such file or directory

This is more likely a problem with Cygwin's path handling, which treats
any path with an embedded '\' as a Windows path that doesn't get
translated into POSIX (so you're not trying to open
'/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices/\DosDevices\C:',
but '\DosDevices\C:'.  Look at the strace to confirm it.  Maybe Cygwin
should check if a path starts with /proc/registry (or any virtual
filesystem) before deciding to not translate it...

> Using a URL-like "%XX" encoding for invalid characters (/\?%) may be the
> right thing to do.
>
> $ ls
> ...
> %5cDosDevices%5cC:

Yep, in effect making /proc/registry a managed mount.  You'd need
something like this anyway to process values that have '/'s in them.

> I found that all standard ascii chars except ^ % ` are used in value names
>
> > 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.
>
> Because POSIX has no notion about file types, the type has to be somehow
> encoded into the name if a new key is created.

What's wrong with using open() flags?

> The major drawback of this approach is that the read path is different
> from the write path.
>
> I would suggest to add a second R/W view to the registry where both path
> are identical.
> A type extension should be added via a rarely used character:
>
> $ ls /proc/registry/SUBKEY
> reg_sz_value
> reg_binary_value
> reg_dword_value
>
> $ ls /proc/registry-rw/SUBKEY
> reg_sz_value,sz
> reg_binary_value,bin
> reg_dword_value,dword

Yep, except I suggested ':'.

> Then you should have the ability to copy subkeys to file trees and vice
> versa:
> cp -r /dev/registry-rw/SUBKEY /tmp/SUBKEY
> rm -r /dev/registry-rw/SUBKEY
> cp -r /tmp/SUBKEY /dev/registry-rw/SUBKEY
>
> Suggest to start a new thread for this discussion....

Right, good idea, except not on this list (as Dave pointed out).  What
would be a good place -- cygwin-developers?
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Christian Franke
Igor Peshansky wrote:
> What's wrong with using open() flags?
>  

Save/restore registry tree in/from file tree wont work.

>> Suggest to start a new thread for this discussion....
>>    
>
> Right, good idea, except not on this list (as Dave pointed out).  What
> would be a good place -- cygwin-developers?
>  
If you consider to accept my subscription request to this list ;-)

Christian

Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Igor Peshansky
On Fri, 3 Mar 2006, Christian Franke wrote:

> Igor Peshansky wrote:
> > What's wrong with using open() flags?
>
> Save/restore registry tree in/from file tree wont work.

If we also add flags for stat() to figure out the type of the registry key
(and we'd have to, for symmetry), copy within the registry would work just
fine.  However, you're right that once the file is copied to the regular
filesystem, all of those special flags are lost.  Hmm...

> > > Suggest to start a new thread for this discussion....
> >
> > Right, good idea, except not on this list (as Dave pointed out).
> > What would be a good place -- cygwin-developers?
>
> If you consider to accept my subscription request to this list ;-)

Did you send such a request? ;-)
I don't have the power to accept it, but, FWIW, I think the above intent
certainly deserves it.  Corinna or CGF?

BTW, Christian, when you're subscribed, read the welcome message carefully
for web archives access instructions.
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] regtool: Add load/unload commands and --binary option

Eric Blake (cygwin)
In reply to this post by Yitzchak Scott-Thoennes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Yitzchak Scott-Thoennes on 3/3/2006 10:41 AM:
>
> as another example of non-traditional access to the registry.  How
> about /proc/registry//machinename/... to access the registry of other
> computers on the network?  Or is // not at the beginning a no-no?

// is only special at the beginning.  Anywhere else in a filename, POSIX
requires /proc/registry/foo and /proc/registry//foo to name the same file.

- --
Life is short - so eat dessert first!

Eric Blake             [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFECjuR84KuGfSFAYARAo38AJwNlRpqrR339r9FqVc+0ZNLRNHOkwCgz4T0
l02999MPTlIgJCPO/UU6cQg=
=mlnF
-----END PGP SIGNATURE-----
12