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

Windows File Explorer: created files aren't visible in Bash #1152

Closed
piotrek-k opened this issue Oct 1, 2016 · 8 comments
Closed

Windows File Explorer: created files aren't visible in Bash #1152

piotrek-k opened this issue Oct 1, 2016 · 8 comments
Labels

Comments

@piotrek-k
Copy link

piotrek-k commented Oct 1, 2016

BashOnWindows has its own folder tree, just like in all linux based operating systems. Reportedly, going to %localappdata%\lxss in windows file explorer should show me all those files.

There is a problem with exploring those files in Windows File Explorer (WFE):

When I create new file in WFE, this file is not visible in bash (ls command doesn't show anything). In opposite way it works correctly: if I create file in bash (touch file.txt) it is correctly displayed in WFE.

Only creating file causes problems. When I create it on "bash side", I can modify/delete this easily on "windows side" and bash sees changes.

Windows Version: 10.0.14393

@aseering
Copy link
Contributor

aseering commented Oct 1, 2016

@piotrek-k -- thanks for posting, but this is a frequently-asked question that's answered on a variety of tickets including (most recently) #1141 , WSL filesystems are discussed in detail in this blog post.

In short, this is expected behavior: Native Linux files require metadata (such as POSIX file permissions) that Windows applications do not understand. %localappdata%\lxss is meant to be opaque data storage for WSL; you're not intended to work with it directly. (Hence its location in %localappdata%.)

If you want to share files between the two environments, you can put them in the Windows filesystem and access them via /mnt/c/ in Linux.

@fpqc
Copy link

fpqc commented Oct 1, 2016

Yes. The way I have taken to explaining it is that it's hidden for a reason.

@taraszka
Copy link

taraszka commented Oct 9, 2016

That's fine but if you break sudoers like I did you won't be able to fix it from the Windows. I think lxss or Microsoft Windows should have some kind of inotify() in place to update the require metadata.

@coldacid
Copy link

There used to be an app available from MSDN downloads that would let you view (and possibly edit) NTFS extended attributes, but it disappeared some time ago. Would be very helpful if the WSL team would dig it out of storage and make it available again, or at least provide a tool that would fix up missing/bad EAs needed for WSL.

@fpqc
Copy link

fpqc commented Oct 12, 2016

@coldacid @RoliSoft wrote a small lib and cmdline tool called ntfsea that you can drive through python. Look in his WSL distribution switcher.

@sunilmut
Copy link
Member

I think these are valuable feedback. We are using user voice page to help us prioritize our work going forward. If you can also provide this feedback there as well, that would be greatly useful.

@RoliSoft
Copy link

RoliSoft commented Oct 12, 2016

@coldacid @fpqc Note: there's no command line app for that currently in the project. Only a C library. That being said, I could create a quick fix_file app which just makes the file reappear again. (By writing something like uid/gid 1000 and set perms to 666 or something.)

@therealkenc
Copy link
Collaborator

The OP was by-design per Adam's post. Topic landing zone is #1524.

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

8 participants