> 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).
Heh, yeh, who could ever forget the .exe/.lnk/.exe.lnk/.lnk.exe troubles?
However, we're in a special situation here, it's not really a dir tree and the
things in it aren't really files, and we may be able to get away with it. I
posted the idea so that others could see if it works or if they can see
problems with the approach.
> 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.
cheers,
DaveK
--
Can't think of a witty .sigline today....
