Avoid collisions between parallel installations of Cygwin

Charles Wilson cygwin@cwilson.fastmail.fm
Fri Oct 16 18:57:00 GMT 2009

Corinna wrote:
> What's clear to me is that the Cygwin DLL is supposed to write its
> fingerprint (key+path) to the registry, along the lines of what Larry
> suggested in the first place.

Yes. (:== matches my understanding of the current consensus)

> What's also clear is that cygcheck is supposed to show the existing
> entries


IMO, it should display both the fingerprint, and the path to which that
fingerprint corresponds.  Note that this would be a different output
section than the current "hunt $PATH for cygwin1.dlls and display those".

> and that it ideally should allow to remove unused ones.


> I'm going to implement that in the next couple of days.  I'm just left
> wondering what is supposed to happen to old entries which don't point
> to an actual DLL:
> - Should cygcheck show them (with a remark "orphaned") or should
>   cygcheck not show orphaned entries at all?

IMO, it should show them with the "orphaned" remark, AND cygcheck should
provide a --remove-fingerprint option.  However, if cygcheck does not
provide an explicit --remove-fingerprint option, then it should not show
the orphaned entries at all.

> - Should cygcheck remove old entries as it goes along (implies not
>   printing them at all), or should it only remove old entries if
>   the user uses some "--clean" option?

IMO, it should not silently remove them. It would be an important clue
that installation "<some hash> C:/some/path/cygwin1.dll orphaned" might
be unintentionally broken somehow.

> What I also didn't get is the result of the other two points.
> - Do we still need a way to switch off using the installation key
>   in object names?  

IMO, yes. But defaulting to "on" is ok, given cgf's acquiescence.

>   If so, using a resource as proposed by Chuck?

IMO, well, it's either there, in an .rc file of some sort, or in a
(installation-key-specific) registry area, since

a) CYGWIN is too late, and too inflexible
b) the 'switch' must be per-installation, not global
   1) thus either rooted in the installation disk image somewhere
      i)  an .rc file
      ii) resource section of the DLL
   2) or in the (installation-key-specific) registry area

+) resources are binary, so very little parsing overhead
+) resources can't get lost, and since they are attached to the
   DLL there's no way they can be the "wrong version", as far as the
   DLL itself is concerned.
+/-) can't be modified while the DLL is in use (+: no expectations
     that changes will take effect while DLL is in use, because it
     can't BE changed) (-: user FAQ: I can't change resource from
     bash shell).
-) requires extra effort to modify -- we have to provide a tool
   to do so. That tool must remain in sync with the current resource
   format. This is easy to do if the tool is part of the cygwin dist:
   eg. cygcheck.  It appears that this tool will be less difficult to
   write than I had feared, given your recent experiments.

.rc file:
+) easy for humans to parse and edit
-) easy for humans to edit incorrectly
-) but machine error checking is hard
-) text-parsing is relatively slow
-) Obviously may only be read once on startup: you don't want
   global object names changing during execution!  But, then
   changes to the .rc won't take effect until all cygwin
   processes are shut down. This could be confusing; more FAQs.
-) missing .rc file

installation-key-specific registry area:
+) the registry is always there
-) installation-key might not be there (if, in 1.7.big_number, we
   provide a way to disable automatic registry litter)
+) formats are easy to "parse"
-) a bit too...self-referential...for my tastes. Using a registry key,
   under the installation hash, to turn off the use of the installation
   hash when naming global objects?  No thanks...and kinda defeats the
   puspose of...
-) using a regkey makes the 1.7.big_number "totally portable"/invisible
   cygwin project harder.

>   If so, what about putting the functionality to change the resource
>   setting into cygcheck?

Well, since cygcheck needs to be able to /read/ it, it'd be silly to put
the write functionality somewhere else.

The big (-) here is mismatch between cygcheck.exe and the cygwin1.dll
that it's modifying.  Suppose the resource section undergoes three
  1) 1.7.0-63
  2) 1.7.2
  3) 1.7.9

Obviously, cygcheck-1.7.2 won't be able to read or write
cygwin1.dll-1.7.9's resources. But should cygcheck-1.7.9 be able to read
or write cygwin1.dll-1.7.2? cygwin1.dll-1.7.0-63?

It's probably safest (fewest number of FAQs) to just punt: a cygcheck
that understands revision #3 of the resource section can only read/write
cygwin1.dll's that contain revision #3 resources -- otherwise, print an
error message and say: "go get the matching cygcheck program".

Note that I'm assuming that there is just ONE cyg resource, whose format
may undergo evolution. An alternative would be that new additions simply
add different resources, with their own names, formats, and
parsing/reading/writing code.  That way lies madness; I think ONE
resource to rule them all is less effort, even if it means some version
hassles as described above.

> - Do we still need a means to switch off the fingerprint creation?
>   This one, I'm not so sure about.  If we really have an interest in the
>   fingerprint, we can't have an interest to provide an easy way to avoid
>   it.  It should at least require to rebuild the DLL, shouldn't it?

IMO, I don't think we need to worry about this for now -- since we
already automatically write to the registry for other reasons (initial
Program Options key creation).  At /most/, for now, guard this new
registry write with an #ifdef, but even that's not really essential at
this point.

Later (1.7.big_number), we can concern ourselves with mechanisms to make
cygwin "invisibly portable" by disabling all automatic registry writes
(perhaps with an additional field in the resources section or .rc file)
But not anytime soon.


More information about the Cygwin-developers mailing list