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: Protect fork() against dll- and exe-updates.


On Mar 30 20:37, Michael Haubenwallner wrote:
> > This behaviour may not be that bad in case of running with a deleted
> > object, though.  On Linux /proc/$PID/maps prints the name of a deleted
> > object with a "(deleted)" tag.  Maybe we can get there, too.  Do we have
> > the information from where the file has been originally loaded still
> > available at that point?  I guess the answer is no...
> 
> When Windows moves some file into trash, IMHO there is some extra info
> file containing the original path. But with Cygwin unlink() ?

We don't write the $I<tmpfilename> and our files are called something
along the lines of .cyg<...> rather than $R<tmpfilename>.  We could
change this but while the original path name is in the $I file, the rest
of the file appears to be undocumented.  No idea if we can reproduce this.
And the DLL info in Cygwin is not accessible from other processes.  Hmm.

> > I'm still not overly excited about using the existence of the dir alone
> > as marker to activate this feature, but that can be added later...
> 
> I could think of some flag to set in setup.exe, but still where to store
> the flag except for the existence of the directory. I'm not sure if the
> registry should be used for everything...

No, not the registry.  The CYGWIN environment variable, perhaps.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature


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