This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin 1.7 release (was Re: ??? The library or libraries will be delivered[...])
On Jun 4 09:06, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > On Jun 3 16:39, Charles Wilson wrote:
> >> "backwards incompatible" [*] changes
> We don't have time between now and $RELEASEDATE to do any of that.
> That's all I'm saying.
> > <rant>
> > And it's really not my fault
> Never said it was. I'm sorry I seem to have hit a nerve. That was
> certainly not my intent.
You didn't hit a nerve. I just took the opportunity to rant about a
really bad decision which makes developer lives unnecessarily harder.
> > This turns out to be sort of a nightmare, but I'm still glad I did it.
> Me too. It's just that it's a user-visible behavior change that we (for
> various values of "we") are still trying to tweak just right. Let's not
> add too many more of those, or we'll never make $RELEASEDATE.
I agree. But it appears to have more unfortunate side-effects than I
> >> 4) removal of registry usage / new mount table
> > That change only affects how mount points are stored. The day to day
> > usage is the same, basically.
> ...except that didn't you (or cgf, or whoever) remove the 'copy over my
> old registry-based mount points to /etc/fstab' code?
No, not at all. The base-cygwin postinstall script still creates
fstab entries from the *system* registry, except for /, /usr/bin, and
The latest change just removed the /etc/profile.d file which creates a
user fstab file from the *user* registry on first start of a shell.
Instead, I moved the script to /bin for manual generation of mount
points. I *think* that's the better solution, but if it turns out to
generate too many complaints, we can move it back to /etc/profile.d
at any given time.
> I'm awake...hey, what's this /etc/fstab thingy?")
You'll never be able to do anything right for that kind of user.
It's the same type not reading announcements or user guides or FAQs.
Erm... that reminds me. Did I create a FAQ for the above change?!?
[...time passes...] Oh, wow, I did. Even a User's Guide entry exists.
*tapping my own shoulder*
> On that note...I've noticed some odd behaviors wrt the dynbase setting
> under Vista. Sometimes Vista will fail to honor that flag, and I'll
> still get the dreaded "*** unable to remap" message. While occasionally
> a reboot will fix it, sometimes not. What's odd, tho, is that
> sometimes I can "fix" it by re-running peflagsall and *removing* the
> dynbase flag (AND rebooting). Then, adding it back (by re-re-running
> peflagsall, and rebooting again) doesn't cause it to break again (at
> least, not immediately). It'll be a week or more before the problem
> shows up again. I haven't spotted any consistent rhyme or reason.
> It's almost as if Vista just needs a kick in the pants by changing the
> last-modified time of all the DLLs. It's all very strange.
I never, ever saw a problem like this on my Vista/2K8 test VMs. Nor on
the W7 VMs. Are you really sure this isn't some BLODA problem?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com