Ubuntu filesystem files may disappear (become not visible in bash) after editing in Windows (e.g. Sublime)

[pavelbulanov]

After editing files from ubuntu file system (originally created there by git clone) by Windows tool (e.g. Sublime) they disappear in bash (become not visible i.e. by ls or git) after some time. (update - see point 7 below, it might be bash restart that cause the issue).
Not sure how to get "lost" files back to bash or verify why the are not visible to bash. They still exist and accessible using windows.

Expected results - files can be edited in windows app and continue to be visible in bash.

Actual results (with terminal output if applicable) - files are completely missing in e.g. "ls -a" output. Git status says that file was deleted (i.e. don't find it).

Windows build number - 14372 (slow ring)

Steps / commands required to reproduce the error:

1. Download git repository inside bash by "git clone". Files are visible in bash and fully functioning, for example I can run "rails s" and it's working.

2. Open source codes from the repository in Windows, e.g. Sublime. The file path is "c:\Users\AppData\Local\lxss\home\pavel\sources\Gemfile". File is perfectly visible and editable under Windows (its content is text, not binary). Do some changes (or no changes at all) and save it.

3. Right after edit the changed file is still visible under bash. I can restart rails server in bash and it uses updated Gemfile (take changes from there). Git status also says the file was modified (therefore can see the file).

=> 4) After some time (not further edits or actions outside of bash needed! - I know it sounds very strange) the file "disappears" from bash. "ls -a" doesn't show it, "git status" says the file was deleted (i.e. also doesn't see it). Windows continue to see the file, I can further edit and save it there (it won't reappear in bash though).

5. If I run "sudo vim Gemfile" it will open the empty file stating "new file" in status bar (it opened the file before w/o problem). I can overwrite the file by saving it in vim without any warnings (and the old gets lost). Same thing if I "git checkout" same file, it gets overwritten w/o any warnings. Sublime then immediately reloads new content (typed in vim or from git checkout) on switching to its window.

6. Notice - today I was able to see "interim" state - 'git status' suddenly said (file was not even opened in Sublime or anywhere)

pavel@computer:~/sources/project$ git status
Gemfile: Input/output error
config/database.yml: Input/output error
On branch master
...

Calling git status right away (no further saving or any other actions outside bash at all!) gave

git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
        deleted:    Gemfile
        deleted:    config/database.yml

And now the file is gone.

7. New founding - if after editing (and disappearing) of a file I close and reopen bash, it can "partly" see the file before first run of the "ls" command inside bash. I.e. - (do edits), close bash, open bash, "cd" to my project folder. Run "vim Gemfile" -> it opens empty screen and says [Permission Denied] in the bottom! I can restart vim many times with the same result, so it can see the file exists somehow. I can not override file at this moment in vim - it will say ""Gemfile" E212: Can't open file for writing". "git checkout Gemfile" now will says "fatal: failed to stat 'Gemfile': Input/output error"

Once I run "ls" or "ll" in bash, the listing immediately doesn't show Gemfile at all (not listed). Re-running vim now will says "New File" and can override it, same as git checkout (after each rewritten file is visible inside bash). After rewrite I can further open the file in Sublime and continue editing, with changes visible to bash. Restarting bash cause the issue (regular and reproducible), and it seemed to be that some waiting (or maybe some operations in bash that cause file directory scanning? - not easily reproducible) will also cause it.

Aspects

1. File permissions under bash doesn't seem to change when editing in Sublime. It's exactly the same before and after save
   -rw-rw-rw- 1 pavel pavel 1685 Jul 15 12:52 Gemfile
   Windows permissions also doesn't seem to be affected as expected (checked properties dialog of a file before and after edit).
2. No symlinks or anything like that used. As said, files are originally created inside bash by git clone. Files are "normal", i.e. work with same repository under "native" Ubuntu (inside virtual machine) works fine, as well as same repository under "native" Windows (using git for Windows and not inside bash).
3. Running new instance of bash won't cause the issue immediately. File is visible in new instance of bash right away.

[onomatopellan]

If you read about VolFs and DrvFs here https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/ you will see why this happens.
Files in VolFs have Extended Attributes that win32 programs as Sublimetext won't conserve when saving.

You should use Sublimetext Linux version. Together with Xming you can open it from WSL even if it's a graphic application.

I have a shortcut with this content in the windows Desktop I use to open linux Sublimetext. (just make sure Xming is already running before running the shortcut)
C:\Windows\System32\bash.exe ~ -c "DISPLAY=:0 /opt/sublime_text/sublime_text"

[pavelbulanov]

Do you envision some other workarounds possible as an options? Many will look like crutches, but why not.

1. Knowing what the issue is and how WSL behaves, make (implement) a special "Open WSL folder" option in Windows editor, e.g. for Visual Studio Code, which is Open Source.
   Should it be technically possible to preserve Extended Attributes inside VolFs from Windows application?

2. Having manual script that "dumps" and then restores EA for specified files (or folder) on demand. I.e. you run "ea_preserve" inside bash on your project folder, do some work in Windows and then call "ea_restore". I know it's cumbersome plus won't work for files newly created in Windows, but can do the work for just editing. Assuming it's technically possible, script shouldn't be too complex.

3. Script to generate EA for files without them inside specified folder. Same as above, but just generate them based on some predefined logic (sufficient for source code files work) and not restore from dump.

Also, unfortunately I can't verify following approach as WSL just broke and won't run after trying edit sources in VS Code instead of Sublime. But should it be possible to work with Windows files inside bash (through mnt and thus using DrvFs) and launch e.g. rails server based on files from windows? Should running applications (ruby in this case) be fully satisfied with such files?

[pavelbulanov]

Also, if this limitation is fixable (no Interoperability with Windows for VoIF) y implementation of WSL, will you point me to the right request on that on User Voice portal?

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/category/161892-bash

[onomatopellan]

The official workaround is using DrvFs (/mnt/*) folders and do git clone there. You can also edit with windows applications like VSCode and files won't disappear or break bash. It should work for most scenarios but for some like compiling Android ROMs is known to have problems.

To start anew and delete everything open cmd and type lxrun /uninstall /full and install bash again with lxrun /install

I'm just a WSL user like you but let's see what Microsoft thinks about your suggestions. The most similar request for the problem would be https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13341279-a-file-created-in-c-users-user-appdata-local-lx

[pavelbulanov]

Indeed, I found an explanation in another issue #87 - #87 (comment)

Long story short:

If Bash is not running: editing a file in most editors will cause the file to disappear from Bash. This is due to some extended data being stripped off by the application on file save (or so I believe right now). I hate to say this, but the only editor I have been able to use reliably is notepad.

If Bash is running: editing the file will show the changes to the file in your current session. This is due to caching on VolFs's side. When you exit Bash and come back in the file will be missing.

Creating or deleting directories on VolFs have the same issues. You can get yourself into odd states this way.

It's a pity that original #45 was simply closed with statement "functions as designed".

[pavelbulanov]

Also, the lucky part for me that simple clearing of "\lxss\temp" folder in Windows fixed bash collapse for me. It starts again.
It broke after I edited couple of code files (from ubuntu filesystem) using VS Code in Windows, presumably because of its git integration which I didn't turn off. As the folder contained .git inside, VS Code tried to operate with it. Although I didn't recall of doing any actions from it (e.g. committing), it seems to make some changes to git files (maybe it executed some git commands of windows git client). And this in turn for some reason broke bash from running - it simply didn't start up. Removing project folder (with those .git files) didn't help.
Cleaning temp resolved the issue. (Actually I simply searched for any files under \lsxx\ that were changed recently and temp was the first location to try).

[rodrymbo]

symlinks work in VolFS. So for a single file make a symlink from the file in lxss land (VolFS) that you want to edit (e.g. .bashrc) to a location in Windows land (DriveFS). Edit with an editor that knows how to handle Linux line endings. I doubt it would work on ..ssh\authorized_keys or other files where permissions matter, but it might work on enough places to make this workaround useful.

If the project doesn't require linux filesystem semantics (e.g. case sensitive filenames, or lots of hard or symbolic links) then do the work in a folder in DriveFS.

One other workaround: I was able to get my Windows editor to stop making a backup of the file (probably moving the original to .bak, and creating a new one, haven't investigated), but rather to edit the file "in place". Apparently this did not mess up the extended attributes, because the file didn't disappear from the lxss environment when bash was restarted. Maybe Sublime has a setting that will allow it to do the same thing? (I'm using build 14390)

It also looked to me as if it is only the last edit that matters, so you might try editing with Sublime while the lxss environment is still open, then opening the file in lxss with vim or something, confirm that the changes are there, and save, perhaps after making a trivial change to allow a real save. When I did that the file was still there when I closed and reopened the lxss environment. (Consider this a one-time test, not a suggestion to give up Sublime and use vim all the time...)

If that works consistently, perhaps a simple bash script could write a LF to the end of each text file (and perhaps delete it again) to make sure it is written in the lxss environment after you finish with Sublime but before exiting the lxss environment. If it works for you, I'd conclude that writing the file in the lxss environment probably puts the extended attributes back.

And of course there is getting X-windows working and using a GUI editor on files in VolFS. That should work.

I know, they're workarounds. But they might allow some people to get work done until the situation changes.

On my build, lxss/temp is completely removed when I exit from the lxss environment. Sounds like a good thing.

[pavelbulanov]

As I need to edit whole project source code (multiple files), setting up individual symlinks won't work.

Same time, keeping files in Windows file system and using them in bash via /mnt/ (DriveFS) seems to work. I can successfully run rails server from files laying on my d drive (NTFS). I can then use any Windows editor, e.g. Sublime or VS Code. Luckily, ruby works OK with edited files in Windows, i.e. with windows style line endings.

I'm also using windows git therefore to work with the github repository. I have core.autocrlf option set to true (default). Again, this seems to be working and ruby inside WSL runs the server OK.

"Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem."

(offtopic) As a result, whole solution works together:

1. WSL Bash running native and latest ruby, installed using standard rbenv and ruby-build. Gems can be installed normally, with possible dependency for some linux libraries (installable via apt-get). Lot of gems tested, including obviously Rails.
2. Databases running on Windows - MongoDB and PostgreSQL, interacting with Rails app natively through standard ports (no specific configuration needed at all).
3. Source code and git are under Windows file system. Editing is done in Windows editors (Sublime, Visual Studio Code, Notepad).
4. Even things like ngrok (localhost tunnel to external world) work and enable testing of webhooks.

[dreyks]

I ended up starting ssh daemon in bash and then mounting my $HOME as an sshfs to Windows

[drankinatty]

I've found a workaround to restore the files to the Linux side of the house after a slight (err, shall we say, resulted in deleting AppData/Roaming on the windows side -- don't ever do that, it is a bitch to get all the functionality back) Anyway, that wasn't the cause of a bulk of my missing files (many like /etc/vim/vimrc and ~/.vimrc were due to editing in notepad++ on the windows side which resulted in the loss of the additional attributes)

To restore them, simply copying them (on the windows side) to some temporary location (like C:\Users\you\temp) then deleting the original (e.g. on the windows side (e.g. del C:\Users\you\AppData\Local\lxss\rootfs\path\to\filename) and finally restoring them from within bash (e.g. cp /mnt/c/Users/you/temp/filename /path/to/filename && chmod 0644 /path/to/filename) did the trick. (note: files that are part of the /home partition will be under C:\Users\you\AppData\Local\lxss\home\you on the windows side)

Hopefully this helps. Again, never "shift+delete" your Roaming directory --- stupid windows focus handling...

[bitcrazed]

@pavelbulanov: Please read this post: "Do not change Linux files using Windows apps and tools"

If you want to edit files using Windows editors like sublime, VSCode, Visual Studio, etc., but build/run your code in Bash, then store your files in a Windows folder, and access that folder via, /mnt/c/dev/..., for example.

[micahgodbolt]

@bitcrazed does that mean I'd need to git clone from a windows CLI as well? Or is the location sufficient?

[joetidee]

Really need this to work, or will be moving over to Mac. Having lack of Linux/Windows interoperability doesn't cut it for application development using node/npm as, even if you git clone to a Windows directory via /mnt/c/... and edit from here using an IDE, still need to run tests/install packages via npm on Linux. Else, what really is point of Linux being available on Windows.

[aseering]

@joetidee -- running node/npm from a git checkout in /mnt/c/... works great for me. When you try to do that, what doesn't properly for you?

[joetidee]

Is this /mnt/c from within bash, or from within C:\Users[USER]\AppData\Local\lxss ?

[joetidee]

Looks like if I create a project in /mnt/c from within bash, I cannot then chown to the ubuntu user (?)

[dreyks]

yes, the /mnt/ filesystem uses windows-side users

[aseering]

@joetidee -- are Linux users important to your development workflow? Again: What, specifically, are you doing that you actually need to do and that breaks?

Don't stop just because something looks wrong -- because /mnt/c is integrated with Windows, its permissions system is just plain different from ordinary Linux, so it's going to be a little different than you expect. (Not saying it doesn't have bugs too :-) )

[joetidee]

I suppose it's just good to be able to ensure that things work as expected as closely as possible to the live environment (which in my case is Ubuntu), where you wouldn't be using root to drive things.

[aseering]

Well, you shouldn't actually have to use root. The files should be listed as being owned by root, but in practice that's because they're being controlled by Windows permissions. So it should be fine to use your regular WSL Linux user account, or any new WSL user account that you might create to mimic your production environment.

If (for example) your environment sets file permissions and verifies that they work as expected within your application, then, yeah, that is a test that's useful that you can't do in DrvFs right now. If that's your use case, it'd be good to know -- the WSL team could help with it in any of several ways, including adding Linux-permissions support for DrvFs or adding Windows-application support for VolFs. (Either way, it's mix'n'matching Windows and Linux permissions.)

[gpakosz]

store your files in a Windows folder, and access that folder via, /mnt/c/dev/..., for example.

@bitcrazed That would work provided regular files in /mnt/.../... were not seen as 0755 by WSL's bash :( Basically cd /mnt/some/project then git add some/file will record 0755 permissions for regular files which you certainly don't want. All in all, it's a deal breaker for me, almost there though keep up the good work

[mateusmedeiros]

@gpakosz Are you aware of the fileMode git config?

You can set it for the current repository using git config core.fileMode false (or you can use the --global flag to set it for all of them).

Don't know if it will be enough for your use case, but there you have it.

[aurimus]

Ah, this is annoying, is there a way I could mount my actual Ubuntu home directory to windows bash? In that way, editing files should preserve the attributes because it's going to be different filesystem

[aseering]

@aurimus -- no, that is not currently possible, in part precisely because of permissions: Most text editors implement "save" as "create a new file and delete the old one." (Very few programs actually update files in place these days. Long story.) So as you edited your files, they would lose their permissions anyway.

[aurimus]

@aseering @bitcrazed an idea, why can't WSL sit on ext4 partition by itself and use Ubuntu own drivers to run things around. While installing WSL it could just create the necessary partition and make it hidden. Thanks. WSL running slow on file access and this issue is really annoying..

[therealkenc]

The OP here was with respect to editing files in "c:\Users\AppData\Local\lxss\home\pavel\sources\Gemfile", covered by Rich's blog post. Landing zone for this topic ended up being #1524, so duping in that direction. There was a lot of filesystem improvements in 17063 that may help this story.