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]

Re: Avoid collisions between parallel installations of Cygwin


Corinna wrote:
> On Oct 21 17:42, Dave Korn wrote:
>>   Hilarity will result the first time someone forgets and uses one of those
>> magic strings in a strace printf because they wanted to dump the value of the
>> setting :)
> 
> Why should somebody use the magic string in strace printf?  It's
> supposed to be there only for the benefit of the external tool
> trying to access the properties settings.  The string can be as
> weird as you like, say
> 
>   qwxcfu!q34ryxifgawxfyiowgxfwyixfgwfoqwexgrffuygfwfyxgywwfwqexfwe

OH! So "name" is really "unique_res_id"  Maybe we should be explicit
about that, and use string-formatted UUID?

struct cygresource {
   char[27] UUID; /* 27 = "550e8400-e29b-41d4-a716-446655440000\0" */
   char[5]  resvd;
   char[N]  readable_name;
   ...
};

Then, in the few places you really need to check for that UUID while
searching the array of resources, the code could embed simple

GUID MY_FIRST_RESOURCE =
  {0x550e8400, 0xe29b, 0x41d4,
   0xa7, 0x16, 0x44, 0x66, 0x55, 0x44, 0x00, 0x00};
and use runtime functions to turn that into the appropriate string.
Hence, no false positives...

>> However, that's just a minor hiccup.  I think it would still be
>> nice to use resources, because it's the system standard way of attaching
>> metadata to a file and there are lots of tools that speak the format.
> 
> Using any kind of self-defined section like ".cygprops" and putting the
> propoerties data into it is still a standard way of attaching data to
> a file.

Well, that's true too. You complain though about the time involved in
the whole FindResource/LockResource deal. But, is that really a problem?
Unless these items are explicitly immutable (and, in the case of the
disable-unique-object-names, it pretty well SHOULD be immutable!), you'd
still need to manage a lock when accessing the global struct that holds
their values, right?

>> From
>> cygcheck's POV it should be able to modify entries in the resource section
>> using just the same binary-in-place-modification trick as you have here to
>> edit the data section shouldn't it?

I know Corinna said the script would allow runtime modification -- but
what (I think) she meant is that you could MAKE the change while cygwin
was still running, but it still won't take effect until the next time
the DLL is loaded into (some processes) memory.  E.g. any future program
startup. But it doesn't apply to any currently executing programs.

And anyway, is that even a good thing?

It seems that you would NEVER want to suddenly change the presumed name
of all global objects, while various cygwin processes are still running.
'Cause now you have some programs running -- for the same installation
of cygwin -- that think the global objects are <over here>, but others
that think they are still <over THERE>.

Requiring that all clients of a given cygwin installation be halted
before modifying THIS particular setting seems like a really good idea,
to me.

> 
> Sure, but it has to be hardcoded and it's in some wau reinventing the
> wheel.  A script is a script is a script.

But a script requires an interpreter, and in our lexicon that means
cygwin1.dll will be in use. I maintain that's a bad thing...

--
Chuck


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