Skip to content
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

File contents differs on mounted Windows drive between Windows and WSL #4064

Closed
pmsanford opened this issue May 24, 2019 · 25 comments
Closed
Labels

Comments

@pmsanford
Copy link

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    Microsoft Windows [Version 10.0.18898.1000]

  • What you're doing and what's happening:
    My setup:

  • Mount location is changed from /mnt to /, so for example C:\Users is at /c/Users
  • I have a directory containing source code for various projects under C:\Users\account\dev
  • I have a symlink from /c/Users/account/dev to /home/account/dev
  • I edit files under ~/dev with editors in Windows, but run tests/servers/etc under WSL

Please note that I am not attempting to edit files under the WSL filesystem from windows; I am editing files in the Windows filesystem from windows and then accessing them from within WSL.

The specific problem I'm posting about is that occasionally when I'm editing files in IntelliJ, the content of the files will stop changing when viewed from WSL. This only started happening with the latest fast ring updates. I haven't noticed this happening with files edited by things other than IntelliJ, but around the latest update I switched to editing python/js with VS Code's remote WSL extension, so that could be a red herring.

If I restart LxssManager or reboot the computer, this is fixed for a while. I have not been able to identify anything specific that triggers this.

Another ongoing issue (which is not a WSL issue) is that editing files with IntelliJ resets their permissions to whatever the mask for the mounted drive is is. I assume (but have not confirmed) this is because IntelliJ writes to files by deleting and recreating them. This could be why only files edited in IntelliJ exhibit this problem.

The file content is the same no matter what method I use to open it (meaning git, with a WSL-side editor like vim, with cat, the binaries built by maven, etc).

  • What's wrong / what should be happening instead:
    Changes made to files in C:\Users\account\dev on Windows should be reflected immediately on /c/Users/account/dev in WSL..
@craigloewen-msft
Copy link
Member

Hi @pmsanford , could you provide more of a repro? Is there a specific way that the changes stop being noticed in WSL? As in, are you already running a server on these files and the changes aren't going over to WSL while the server is running (and if so, which server?), or are you not seeing the changes using commands like cat, etc.

Any more description, or list of command line arguments you use would be helpful!

Thanks!

@pmsanford
Copy link
Author

@mscraigloewen Unfortunately I haven't been able to notice a specific set of steps (other than editing in IntelliJ as mentioned before) as the way this manifests is usually fairly confusing and I don't notice until I've made other changes troubleshooting. This has only happened 4 or 5 times so far.

This occurs in a Java project I'm working on, so the usual way I discover it is that I'll make some changes (in IntelliJ on Windows), rebuild the project (on WSL), run it (on WSL), and the changes I've made will not be reflected in the output of the program. I'll then go back to the IDE (running in Windows) and check that the changes are present and saved; I can view them with something like Notepad, VS Code (also running in Windows), or Get-Content in PowerShell and the changes are reflected there as well. If I view them using anything on the WSL side (cat, vim, etc) the content does not match what I see from apps on the Windows side (it reflects the content from before my edits). Restarting LxssManager (or my entire PC) fixes this and they sync up again.

I haven't seen this since the last fast ring update (18908.1000) but I've also been on PTO. Will update if this happens again and try to nail down more specifically what I was doing before it happened.

@craigloewen-msft
Copy link
Member

Okay great! Anything reproducible that we could quickly test would be helpful. In the meantime I'll try out your setup and see if I can repro. Please ping this thread if you have any updates!

@pmsanford
Copy link
Author

pmsanford commented Jun 7, 2019

This happened again today - I had been editing the same Java project with VS Code Insiders using the WSL Remote extension and I switched to IntelliJ editing by local file path and some of the first changes I made caused a desync. I didn't do anything special - I edited a test file and saved and they went out of sync. I realized I didn't post my wsl.conf in the initial post:

[automount]
root = /
options = "metadata,umask=22,fmask=11"

and my current ver: Microsoft Windows [Version 10.0.18908.1000]

ETA: This initially started happening before the vs code remote extensions were released - I don't think that's related.

@craigloewen-msft
Copy link
Member

Yup I was able to repro your problem! Here's the steps I used:

  • Set my wsl.conf file to the one that you had and restarted my distro
  • Ran the commands:
cd wsldev3
notepad.exe test.c
  • Edited the file in notepad in test.c and saved it
  • cat ./test.c gives the earlier version of the file

We'll take a look at this bug! Thanks for posting the issue.
@SvenGroot

@canselcik
Copy link

canselcik commented Jun 11, 2019

I am having this issue as well. It is a recent regression as far as I can tell from my timeline.

Calling sync; sync in WSL seemed to have taken care of if at least once, but it keeps coming back and at this point it doesn't sync using that workaround either. So that was probably a coincidence.

Looks like IntelliJ is able to know that the write failed, however the reason isn't displayed. This might have something to do with the use of inotify inside WSL because as far as I can tell, if the program using inotify inside WSL is terminated, and the file is edited again in Windows, the write succeeds and the files in question go in sync.

@seanf
Copy link

seanf commented Jun 26, 2019

This just started happening to me after Windows upgraded to 1903 (build 18362.116).

I'm using Pengwin (with C:\ mounted as /c) and editing Windows files in IntelliJ. I can cat the same file from Cygwin Bash and WSL/Pengwin and see two different files. sync; sync doesn't help.

EDIT: Just to clarify, I'm using WSL 1. (Pretty sure WSL 2 isn't an option on 1903.)

UPDATE: Looks like the timing was a coincidence. Reverting to 1809 (17763.557) hasn't helped.

@imWayneWY
Copy link

I have the same problem and I am using nodejs. Is there any temporary way to fix it?

@canselcik
Copy link

@imWayneWY Turn off the program using the inotify API or disable its use by the program and writes from Windows should begin to work correctly immediately on the next save.

@imWayneWY
Copy link

@mscraigloewen I don't know whether it helps but it seems like the files's modified date haven't been changed. I still use git in WSL and the remote repository give me the wrong date.

@qiuwch
Copy link

qiuwch commented Jul 15, 2019

For me it seems the VS Code's remote WSL extension caused the issue. I saw different file versions in vscode WSL and visual studio. And this discrepency caused the loss of a whole night programming because the git in vscode saw a different version than visual studio.

Hope this information helps.

@pmsanford
Copy link
Author

I've never had this issue editing with VS Code. Just an educated guess, but I think it's more likely the editing with Visual Studio is what caused the issue. VS Code was just seeing the stale versions like any utility in WSL would. That aligns more with my experience.

@m-7761
Copy link

m-7761 commented Mar 27, 2020

How can I fix my WSL when this happens? Logout of Windows? Everything on the WSL side is stale. Everything on non-WSL is correct.

For me I think this is caused by file-locking issues because I'm pretty sure Vscode uses a completely messed up way of handling (microsoft/vscode#23107) file/edit ownership (unlike any text editor) that I'm pretty sure locks the files somehow once you edit them. And I think this persists when you open/close Vscode as long as the tab is open.

@dstarkebaum
Copy link

dstarkebaum commented May 22, 2020

I am having the same problem, and it was driving me crazy, but this thread has helped me to pinpoint the source of the issue (VS Code, Remote WSL extension)!

My system:
OS Name: Microsoft Windows 10 Enterprise
Version: 10.0.18362 Build 18362
WSL1 (Hyper V), running: Ubuntu 18.04.4 LTS
Kernel Version (uname -r): 4.4.0-18362-Microsoft
Note: I have my C drive mounted as /c/ instead of /mnt/c/
I am using ConEmu as my terminal

Here is the issue as I experience it:

  1. Create a file in Excel (Windows), and save as csv to a folder in my C drive (C:\Users\username\dev\test.csv)
  2. Navigate to /c/users/username/dev, check the file exists (ls), and it is indeed there.
  3. Read the file in WSL (less test.csv), and confirm the contents are correct.
  4. Edit the file in Excel, and save over the same filename.
  5. Read the file again. Contents have updated (Hooray!)
  6. Start up VS Code through WSL in the same directory (code .)
  7. Edit the file (test.csv) and save it again using Excel
  8. Read the file in WSL (less test.csv), and it still shows the old version! =(
  9. Save the file with a new filename (test2.csv)
  10. check the directory in WSL again (ls), and indeed I see the new file
  11. Read the new file in WSL (less test2.csv), and the contents are correct.
  12. Modify the file (test2.csv) in Excel
  13. Read the file again in WSL (less test2.csv), but the contents are still unchanged! =(
  14. Close Excel, then rename the file in Windows Explorer (test2.csv -> test3.csv)
  15. Check in WSL (ls), and the filename has changed.
  16. Read the file in WSL (less test3.csv), and the contents have changed!

It appears that I only have this problem while VS Code (Remote WSL) is running. I am not yet sure what is the reason for this (maybe documented in the VS code Github somewhere).
However, if I just close out VS code, then all of the files seem to stay in sync.

Note: It turns out that if I just run VS code directly in Windows (disable the Remote WSL extension), then I no longer have this problem. So, I will just do it that way from now on. (makes it harder to use the iPython terminal and python debugger in VS code because I would have to maintain the same python libraries in both environments, but I wasn't using those tools much anyway)

@fredlebel
Copy link

Encountered this issue and in my case it was ng serve under WSL preventing WSL from syncing with Windows under /mnt/c/.... Seems related to inotify API which is probably used by Angular for code change detection and automatic rebuild.

Just killing the ng serve process fixed the problem and previous changes done in Windows were immediately visible in WSL.

@m-7761
Copy link

m-7761 commented Sep 17, 2020

Encountered this issue and in my case it was ng serve under WSL preventing WSL from syncing with Windows under /mnt/c/.... Seems related to inotify API which is probably used by Angular for code change detection and automatic rebuild.

Just killing the ng serve process fixed the problem and previous changes done in Windows were immediately visible in WSL.

Is ng serve or inotify a first-party component of WSL or is it just regular software that happens to be triggering something in WSL to fail? This bug makes vscode unusable with WSL projects. If you can see a path forward it would be helpful to notify the authorities.

@xmnboy
Copy link

xmnboy commented Oct 25, 2020

Confirmation that I am seeing the same problem that @dstarkebaum described above. VSCode on WSL is causing my WSL environment to not see changes made on the Windows side of the fence. Both sides are operating on files that are managed by the Windows file system (e.g., C:\Users\paul\Desktop\temp.txt on the Windows side and /mnt/c/Users/paul/Desktop/temp.sh on the WSL side.

p.s. Current Windows 10 system as of date of this post. No special dev releases. Happens with both WSL1 and WSL2. Ubuntu WSL distributions.

@wiliamwalace
Copy link

Same problem, in my case it is pptx files edited with Powerpoint that are not synchronized. I was able to reproduce the problem described by @dstarkebaum with Excel and I had another finding. During the reproduction test, I parallelly edited another text file with Notepad, and the Notepad modifications were correctly reflected, no matter VS Code with remote extension was running or not. It seems a conflict between certain Microsoft software.

@hzhangxyz
Copy link

Same here, it seems this issue happend when I open both of vs and vscode, after I close vscode and save file again in vs, the file sync

@Scytmo
Copy link

Scytmo commented Dec 14, 2020

There is a work-around in VSCode that I have found effective. If I enable the setting "Remote.WSL > File Watcher: Polling", then VSCode polls for file changes rather than using file change events from the operating system (which I believe is what causes the problem). With this option enabled, I don't suffer from the problem any more.

Obviously, this is only a useful work-around for those people who are suffering from this problem only due to VSCode - some people appear to be reporting problems due to other programs that are causing the same problem due to the use of file change events.

@rekire
Copy link

rekire commented May 22, 2021

I just observed the same behavior while using Visual Studio code.

On the wsl bash I see this:

$ sha1sum /mnt/c/Users/me/Programming/Foo/sample.js
5d084c7a79dd39da7b0c98372561c5145fd6a1e5  /mnt/c/Users/me/Programming/Foo/sample.js

On windows cmd:

C:\Users\me\Programming\Foo>sha1sum sample.js
cab0f8d2cf6c9c988425ee5424c96ef97de2b3ed *sample.js

Very strange to see that

After I closed all wsl instances it started working again as expected

@rcmosher
Copy link

I was able to get my file contents back up to date running wsl.exe --shutdown. Probably unmounting and remounting my Windows directory from WSL would have also done it.

I'm not sure what caused this. I'm also running ng serve, but also did a number of git branch switches (from Windows) in between creating these files in WSL and them disappearing.

@drzow
Copy link

drzow commented Sep 20, 2021

I'll have to throw a Me To in here! Lost a fair deal of work due to changes getting overwritten with an older version of the file. Here's my setup:
ver: Microsoft Windows [Version 10.0.22000.194] (I guess that string hasn't been bumped to 11 yet)
VSCode 1.60.0 running Remote Connection to WSL2 (Kernel version: 5.10.43)

I was accessing my project on OneDrive through WSL2 (so /mnt/c/Users/user/OneDrive/Project) which was working fine until I got a first cut done and moved the project into git -- that's when I started noticing problems. Okay, running git on WSL2 on OneDrive -- I get how that might be too many levels of indirection, so I moved the repository to be local on WSL2 (/home/user/Project) and still had problems, so I pulled the files out of git, still running local to WSL2 (/home/user/ProjectNoGit) and I am in a state where I vi the file in WSL2, make a change, save-and-quit, then less the same file and I do not see my change that I just made in vi.

When I quit VS Code (with the remote connection), I could not repo, and when I try @Scytmo's recommendation to turn on polling (which is supposed to be for WSL1 but seems to help here as well) so it's like VS Code's Remote Connection (probably something with the file watcher) is keeping the old copy of the file open and sometimes WSL is reading the new one, and sometimes the old one. It may well be that I had this problem all along, but the addition of git exaggerated it to the point I noticed it? 🤷

Copy link
Contributor

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!

@rekire
Copy link

rekire commented Feb 3, 2024

This bug is still there. Something is changing the line endings transparently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests