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] |
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] |