On Apr 23 10:15, Corinna Vinschen wrote: > On Apr 23 01:44, David Macek wrote: > > Hello everyone. > > > > Some time ago, I encountered a problem in a script when run on Cygwin/MSYS2. To add some drama, I'll mention that the problem caused some data loss (nothing important though). The problem is that some operations on open files seem to fail on subst'd drives (but not on regular ones). > > > > To reproduce the problem, choose some writable directory and run: > > $ subst X: C:/somesubdir > > $ cd /cygdrive/x/ > > $ touch foo > > $ { rm foo; touch foo; } > touch: cannot touch 'foo': Permission denied > > > > (Do not subst to just C:/, because that somehow doesn't lead to the error.) > > > > There's also a C program that does essentially the same thing: > > > > I compared this with the same operations running on a regular drive, > > but I couldn't find any difference in how `rm` deletes the file nor in > > how `touch` creates the file. Just the result of the last NtCreateFile > > is different (STATUS_SUCCESS vs. STATUS_DELETE_PENDING). > > It's a result of how Cygwin tries to workaround the weird Windows > behaviour that a deleted, but still opened file is not invisible in the > filesystem, as desired per POSIX. Cygwin then tries to move the > file out of the way, on local drives into the recycler. This fails > on a subst drive pointing to some subdir apparently, so Cygwin just > falls back to what Windows does. > > I have no simple workaround for that. In theory there should be a > way to check the drive for being a virtual drive and then using the > recycler of the drive it's pointing to for the aforementioned operation. I hacked a bit on that and it seems the solution was easier than I thought. I uploaded new developer snaphshots to https://cygwin.com/snapshots/ Replacing the Cygwin DLL alone is sufficient for testing. Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat