Protect fork() against dll- and exe-updates.

Corinna Vinschen
Tue Nov 17 13:48:00 GMT 2015

On Nov 16 19:07, Michael Haubenwallner wrote:
> On 11/16/2015 11:22 AM, Corinna Vinschen wrote:
> > On Nov 16 10:01, Michael Haubenwallner wrote:
> >> On 11/14/2015 11:25 AM, Corinna Vinschen wrote:
> >>> On Nov 13 17:12, Michael Haubenwallner wrote:
> >> Also, for the dll-redirection to work, all the linktime
> >> dll's need to be available nearby app.exe and the app.exe.local file,
> > 
> > Ok.  We're talking about pre-installed binaries in the first place,
> > right?
> What do you call pre-installed binaries? It doesn't matter for the
> binary when and by whom it was installed, either setup.exe - which
> is non-cygwin, or some in-cygwin package manager - which relies on
> the update-safe fork when replacing in-use binaries.

What I meant was binaries in the distro tree in contrast to out-of-tree
binaries.  I was just thinking aloud about the need (or lack thereof) to
handle binaries installed on drives other than the Cygwin installation

> > I'm not yet clear on how this is going to handle binaries
> > installed to another drive...
> For now, when NtSetInformationFile (FileLinkInformation) does fail
> for whatever reason (I cannot think of anything else than another
> drive), this file is not hardlinked and will be used from its original
> location. Must admit I haven't tested this scenario.

Ok, something to keep in mind.

> >> either as hardlink, copy, or symlink(?).
> However, I can imagine two different cross-drive approaches:
> * Either create some cygfork-directory on each drive to hold the
>   hardlinks (still requires NTFS), and put symlinks into /var/run/
> * or do a file-copy using the pre-opened handle into /var/run/
>   (should work even with FAT, but would be slow).

I realize that we don't have to handle this at all.  The problem your
patch is supposed to handle are installation issues, which usually only
occur for installer-provided binaries, so only distro binaries should be

> >> Otherways we might have to
> >> create some app.exe.manifest file - I've got lost in that docs...
> > 
> > Heh, yeah.  The manifest is pretty ugly, IMHO, especially the
> > compatibility stuff since Windows 8.1.
> > 
> >>>> More to discuss?
> >> ATM, there's one thing I'm unsure whether it is necessary at all, and how
> >> to do if yes: Purging the bin - where the hardlinks get moved to.
> > 
> > We look into that when we get to it.
> Ok then.
> > Btw., I just skimmed your patch a bit and I stumbled over the usage of
> > GetFileInformationByHandle.
> Is there something wrong with GetFileInformationByHandle I should know of?
> It can return FileId, LastWriteTime, and FileSize in one call...

Not as such, no.  It's just that Cygwin isn't using the Windows calls.
Under the hood the GetFileInformationByHandle is calling
NtQueryVolumeInformationFile(FileFsVolumeInformation) and


We're not using FileAllInformation anymore because in my (very, very
long ago) testing, FileAllInformation needed a big buffer to store the
file's pathname.  However, I just tried it again while looking into
this, and it turns out that you can call FileAllInformation with a
buffer of size FILE_ALL_INFORMATION (which only has room for the first
character of the path).  It returns STATUS_BUFFER_OVERFLOW, but it also
returns all the data in the structure.  Yay.

I think I did some tests way back when, which showed that
FileAllInformation could be slower than three single calls
FileBasicInformation, FileStandardInformation and
FileInternalInformation combined.  But that was back in XP times.  If my
test results are outdated and FileAllInformation is quick enough, we
should contemplate to use FileAllInformation instead of
FileNetworkOpenInforation in class path_conv.  This may drop some
conditional code paths and generally simply the code a bit...

> > In dll_list::ctimename, please use NtQueryInformationFile with
> > FileBasicInformation instead.  It allows to reduce the filetime
> > comparison to a single test using the QuadPart of the timestamp and
> > __small_swprintf simply uses a %016X.
> Actually the FileInformation queried in dll_list::ctimename is reused
> in dll_list::update_forkables_needs - have added a comment now.


> > Analogue in dll_list::update_forkables_needs.  Do you really need to
> > check the volume serial number?  Otherwise, just call
> > NtQueryInformationFile(FileInternalInformation).
> The idea behind checking the volume serial number is that I'm unsure
> whether dlls can be replaced by symlinks to other drives as well, so
> the FileId probably could become equal for different files...

Symlinks can't be used for various reasons, not the least of them
the fact that non-admin users can't create them by default.

> BTW: MSDN document for FILE_INTERNAL_INFORMATION structure tells about
> IndexNumber as the member - and so does /usr/include/w32api/, but
> winsup/cygwin/ntdll.h does name it FileId - caused me some confusion...
> Is that intentionally?

It's historical.  FileId is the name of the field as used by Gary
Nebbett's book "Windows NT/2000 Native API Reference", heavily used when
MSDN had even less documentation of the NT API.  Unfortunately there was
never a followup book :(

I'd be not too sad to get patches changing this to the currently blessed


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin-developers mailing list