-
Notifications
You must be signed in to change notification settings - Fork 836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perl deletes files when using in-place edit #966
Comments
Alternative command that also deletes (showing it isn't the fault of xargs):
|
The mystery continues ... I cloned the original repo and cannot reproduced the problem today, and could not reproduce it with your minimal example either, very strange. |
It looks like a duplicate of #904 What it probably happened is that the git directory was manipulated by Windows Git or manually through the lxss folder. Changing the contents of that folder from Windows side can corrupt files and even make them disappear. Use always linux tools to manipulate files from folders like |
I can confirm I had been using Windows Git on the repo ... but, it is only under lxss via symbolic link:
|
I can reproduce this consistently - it seems like it only fails for files in DrvFs:
|
This may be a similar issue that's happening in #1615 |
This is a known limitation in our unlink support for DrvFs. In LxFs, we emulate unlink by renaming the file to a temporary directory, but in DrvFs we cannot do that so we use normal Windows delete semantics. Perl attempts to open the file, unlink it, recreate it, then copy data from the old file to the new. On DrvFs, after step 2 the file is not unlinked, but merely marked for deletion because there is still an open handle to it (from Perl itself). Recreating the file then fails because opening a file marked for deletion is not possible. When Perl closes the first file descriptor, the file is actually deleted. We realize this is a very unfortunate limitation, and we're working on ways to improve our file system support to fix this issue in a future insider build. |
@therealkenc - good call, I'll dupe that one out as well. |
@SvenGroot while you are in there looking at "filesystem stuff", please see if you can squash #1529. It looks like the Meteor people are hitting it as well. The core issue here isn't about "unlink"; it's about NT semantics on open handles. You already know that of course. Just didn't want #1529 lost in the noise. |
Very nice. So... how'd ya fix it? Or, put another way, what's the catch? |
@therealkenc We changed NTFS-based DrvFs volumes to use "POSIX unlink" instead of the "regular Windows delete". (FileDispositionInformationEx instead of FileDispositionInformation) |
Oh that's totally cheating. That wasn't even there before. 😊
|
Finally got to test this on 16193 and believe it to be working. I've been able to run all dev work via my c drive. Thanks! |
I'm still seeing this in 10.0.16299.15, having webpack watch a directory and then deleting a file from windows explorer causes it to stick around until webpack is killed. Edit: Updated to 16299.19 and it's still happening, see this comment for more: #1956 (comment) |
Hm, what just happened? I just left a comment... |
This one was left in an undead state and has been long addressed circa spring 2017. Pronoun "this" here being the repro given that doesn't presuppose some existing directory structure (as with the OP), which was (paraphrasing):
To the extent there exists other gaps in the 9p filesystem, they are not this. |
I can reproduce it in WSL (ubuntu) OS Version 10.0.18363 N/A Build 18363 |
Please use the following bug reporting template to help produce actionable and reproducible issues:
The following kind of one-liner can be used to do a recursive find and replace:
However, this currently deletes all found files in BashOnWindows.
From a Linux system:
Note the last line confirms deletion.
14393.51
See above commands.
perl
See our contributing instructions for assistance.
The text was updated successfully, but these errors were encountered: