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

Filesystem problems: Consolidated #1051

Closed
SRGOM opened this Issue Sep 5, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@SRGOM
Contributor

SRGOM commented Sep 5, 2016

Consolidated problems.

@iz0eyj

This comment has been minimized.

Show comment
Hide comment
@iz0eyj

iz0eyj Sep 5, 2016

@SRGOM Yesterday I ran into a problem, seemingly random, in the management of access rights.
I have many directories mapped through symlink to the Win side and yesterday the MonoDevelop could not modify the files contained in one of them.
I haven't reported it because I can't figure out how to replicate it.
I also had the problem of the files created and/or modified on the side Win not visible from WSL but I don't opened a thread because he had already been reported.

iz0eyj commented Sep 5, 2016

@SRGOM Yesterday I ran into a problem, seemingly random, in the management of access rights.
I have many directories mapped through symlink to the Win side and yesterday the MonoDevelop could not modify the files contained in one of them.
I haven't reported it because I can't figure out how to replicate it.
I also had the problem of the files created and/or modified on the side Win not visible from WSL but I don't opened a thread because he had already been reported.

@rodrymbo

This comment has been minimized.

Show comment
Hide comment
@rodrymbo

rodrymbo Sep 5, 2016

Just a quick note here until the Devs get back from Labor Day Weekend:

Makefile and makefile are different files to NTFS and Linux/WSL, but until lately Windows has been blocked from making both files in the same folder because Windows is insensitive to difference in case. It still gets confused because it can't tell the difference. Linux relies on this behavior (case sensitivity), so it has been made available on the WSL side. Since Windows doesn't handle it very well, when you use it in a folder on the WSL side, don't use that folder with Windows, or if you do, expect strange things to happen.

The VolFS file system (all file paths that don't begin with /mnt, such as /home) has been set up to be much closer to Linux standards than is normally available under Windows. Consequently the Windows side hasn't been able to create files properly in VolFS, and it may never get this capability. %LOCALAPPDATA%\lxss has been hidden from Windows, which some might think is a clue not to use Windows there. If you need to access files in VolFS (e.g. /home/whatever) first use Bash.exe to copy them to someplace that begins with /mnt, then use Windows to your heart's content on them, then use Bash.exe to copy them back when you are done. (At least for now.)

Yes those are inconsistencies, but they are pretty well known. Whether they are bugs or features is another story. If you accept the two rules (don't use the WSL to create both Makefile and makefile in folders where Windows might need to read them, and don't use Windows to access files in %LOCALAPPDATA%\lxss) things actually aren't too bad. If you break those rules, inconsistencies can be expected.

You might be able to get more traction suggesting how those design decisions should have been handled on the Uservoice site.

The handling of symlinks and hardlinks has been problemmatic. The current design seems to rely on different functionality for it between the WSL side and the Windows side. The design decision that was made says that NTFS symlinks and other reparse points probably won't work from the WSL side, and symlinks and hard links made while you are in Bash.exe (WSL) won't work on the Windows side. Some of us think that at least existing NTFS reparse points should be honored/followed when encountered in WSL (assuming permissions allow) even if you can't create or change them while in WSL. But that's not how the devs implemented it. So for now, you might want to use a naming scheme or something so you can tell which ones were made (and can only be used) in WSL, and which are reparse points in Windows that won't work properly in WSL.

Good luck enumerating these and other inconsistencies.

rodrymbo commented Sep 5, 2016

Just a quick note here until the Devs get back from Labor Day Weekend:

Makefile and makefile are different files to NTFS and Linux/WSL, but until lately Windows has been blocked from making both files in the same folder because Windows is insensitive to difference in case. It still gets confused because it can't tell the difference. Linux relies on this behavior (case sensitivity), so it has been made available on the WSL side. Since Windows doesn't handle it very well, when you use it in a folder on the WSL side, don't use that folder with Windows, or if you do, expect strange things to happen.

The VolFS file system (all file paths that don't begin with /mnt, such as /home) has been set up to be much closer to Linux standards than is normally available under Windows. Consequently the Windows side hasn't been able to create files properly in VolFS, and it may never get this capability. %LOCALAPPDATA%\lxss has been hidden from Windows, which some might think is a clue not to use Windows there. If you need to access files in VolFS (e.g. /home/whatever) first use Bash.exe to copy them to someplace that begins with /mnt, then use Windows to your heart's content on them, then use Bash.exe to copy them back when you are done. (At least for now.)

Yes those are inconsistencies, but they are pretty well known. Whether they are bugs or features is another story. If you accept the two rules (don't use the WSL to create both Makefile and makefile in folders where Windows might need to read them, and don't use Windows to access files in %LOCALAPPDATA%\lxss) things actually aren't too bad. If you break those rules, inconsistencies can be expected.

You might be able to get more traction suggesting how those design decisions should have been handled on the Uservoice site.

The handling of symlinks and hardlinks has been problemmatic. The current design seems to rely on different functionality for it between the WSL side and the Windows side. The design decision that was made says that NTFS symlinks and other reparse points probably won't work from the WSL side, and symlinks and hard links made while you are in Bash.exe (WSL) won't work on the Windows side. Some of us think that at least existing NTFS reparse points should be honored/followed when encountered in WSL (assuming permissions allow) even if you can't create or change them while in WSL. But that's not how the devs implemented it. So for now, you might want to use a naming scheme or something so you can tell which ones were made (and can only be used) in WSL, and which are reparse points in Windows that won't work properly in WSL.

Good luck enumerating these and other inconsistencies.

@GSam

This comment has been minimized.

Show comment
Hide comment
@GSam

GSam Oct 14, 2016

@rodrymbo

Consequently the Windows side hasn't been able to create files properly in VolFS, and it may never get this capability.

I've managed to get a guest share running of Samba's smbd that is plausibly accessible from Windows. That provides an interesting avenue to this overall problem.

GSam commented Oct 14, 2016

@rodrymbo

Consequently the Windows side hasn't been able to create files properly in VolFS, and it may never get this capability.

I've managed to get a guest share running of Samba's smbd that is plausibly accessible from Windows. That provides an interesting avenue to this overall problem.

@rodrymbo

This comment has been minimized.

Show comment
Hide comment
@rodrymbo

rodrymbo Oct 15, 2016

@GSam - it's actually pretty simple to get the ssh server running, at which point one can use sftp to access files in VolFS. Several programs I know and use (e.g. Notepad++) can access SFTP servers pretty much as readily as local filesystems.

Congrats on getting Samba running! Don't say it too loud or others will ask you how you did it. ;)

@GSam - it's actually pretty simple to get the ssh server running, at which point one can use sftp to access files in VolFS. Several programs I know and use (e.g. Notepad++) can access SFTP servers pretty much as readily as local filesystems.

Congrats on getting Samba running! Don't say it too loud or others will ask you how you did it. ;)

@vpArth

This comment has been minimized.

Show comment
Hide comment
@vpArth

vpArth Dec 6, 2016

Yeah, @GSam, how you did it? Using some patched version? Original smbd failed to start because can't to get network interfaces...

vpArth commented Dec 6, 2016

Yeah, @GSam, how you did it? Using some patched version? Original smbd failed to start because can't to get network interfaces...

@therealkenc

This comment has been minimized.

Show comment
Hide comment
@therealkenc

therealkenc Jan 13, 2018

Collaborator

Ran course. CONTRIBUTING.md

Collaborator

therealkenc commented Jan 13, 2018

Ran course. CONTRIBUTING.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment