Any plans of hiding "Windows hidden files" on WSL bash?

[mths0x5f]

Now that %userprofile% is mounted as the ~ directory, became clear to me that NTUSER.DAT and a thousand others system files are unnecessary shown to WSL. So, is there any plans of hiding "Windows hidden files" on WSL bash? They are already specially treated as accessing them was causing BSoD. Hiding them, to me, is a step forward to prettify ls output.

On the other hand, *NIX applications tend to store configuration files on home directory using the dot convention, and then %userprofile% became full of dotfiles. Any plans of automatically applying the atribute on Windows-side when a .dotfile is created on WSL?

[benhillis]

Matheus (@mths0x5f) Great questions! A couple of clarifying comments.

1. The ~ directory does not actually map to %userprofile%. The user home directory is in %localappdata%\lxss\home (or %localappdata%\lxss\root for root). If you launch bash.exe from a cmd prompt it will launch in the current working directory of the cmd prompt. You can launch in your user's home directory by typing "bash.exe ~"
2. The bluescreen caused by opening the NTUSER.dat files has been fixed. The open will now fail and you won't be able to bugcheck the machine. Previously we had a bug in the lookup failure path for these types of files but that was fixed.
3. Russ Alexander (@russalex) has a great writeup on the differences between the /mnt/ drive mounts and the Linux filesystem.

[mths0x5f]

Ben Hillis (@benhillis) I'm running build 14352. Update was applied yesterday.

SECOND EDIT (I sincerely apologize saying this is default behavior):

I decided to reinstall the image using lxrun and this behavior is gone. So I remembered one of the things I tried first was mapping ~ to %userprofile%, but gave up when it didn't work. At that time, I was editing /etc/passwd. Weeks later, after an update it works and I didn't remember. I'm sorry. 😞

But questions still valid if in the future, if mapping ~ became a feature.

The ~ directory does not actually map to %userprofile%.

That's weird. I swear I can ls ~ and actually see %userprofile% content...

FIRST EDIT:

I've just tried and well... a picture is worth a thousand words:

The bluescreen caused by opening the NTUSER.dat files has been fixed.

Yup, I know. what I'm proposing is about this:

As you can see, ls ~ output even files with no reasons to. They're in the folder but they can't (and shouldn't) be accessed inside WSL, so what is the point of this kind of file being visible?

Obs.: You can also notice on background, .bash_history, .ssh/, .dbus-keyrings/ and .python_history, files created by *NIX applications inside WSL.

Thanks for your response.

[benhillis]

Matheus (@mths0x5f) No problem at all! As you noticed we now support changing your user's home directory, and that directory can be somewhere under /mnt/c/. There may be things that do not work 100% due to the differences between VolFs (the Ubuntu file system) and DriveFs.(/mnt/c). We have a blog post and video coming soon that will explain some of the differences in great detail.

You do raise an interesting point about what files should show up in DriveFs. Right now we don't do any kind of filtering on what files show up in directory listings for DriveFs but it's something we can consider in the future.

[niftyhacking]

On Wed, Jun 1, 2016 at 5:43 PM, Ben Hillis notifications@github.com wrote:

Matheus (@mths0x5f) https://github.com/mths0x5f No problem at all! As you noticed
we now support changing your user's home directory, and that directory can
be somewhere under /mnt/c/. There may be things that do not work 100% due
to the differences between VolFs (the Ubuntu file system) and
DriveFs.(/mnt/c). We have a blog post and video coming soon that will
explain some of the differences in great detail.

You do raise an interesting point about what files should show up in
DriveFs. Right now we don't do any kind of filtering on what files show up
in directory listings for DriveFs but it's something we can consider in the
future.

Caution hiding things can prove a mixed bag.
Perhaps require a special group ID that is normally not assigned.
There may be a dozen+ files where the answer is obvious to MS but this is
where aspects of MS security and *niux security differ at times.
See "ls -M " and other extended file attributes for security enhancements
to Linux.
https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.bpxa500/ls.htm

The value is that done correctly file system attributes could make it
obvious why a file
or directory is closed. Ad-hock filtering would add confusion to places
where clarity
makes the difficult possible.

T o m M i t c h e l l

[shurane]

I understand there is a grander scale at play, but I resorted to a simple ls alias I found off of superuser.com and modified for my needs:

alias ls='command ls --human-readable --group-directories-first --color=auto -I NTUSER.DAT\* -I ntuser.dat\*'

At least for short term, this solves the problem of hiding all those pesky NTUSER.DAT files that I am not interested in.

[embray]

To me it's mostly an annoyance when running ls (and this is not unique to WSL--this has annoyed me for years on Cygwin too). I've considered just building my own patched ls that by default excludes Windows hidden files.

[therealkenc]

This circa 2016 one is more or less tag linux-behavior. If you mount a exported C:\ Samba share or a ntfs-3g filesystem on Real Linux you'd see the same (agreeably annoying) behaviour. The Linux kernel (and by extension) WSL doesn't know what files are hidden and which are not hidden; there is no hidden attribute in *nix. It's a user-space thing. There are a number of ways to skin this cat, but it isn't WSL actionable.

[adeolemon]

I ended up writing an ls() function that takes --ignore arguments from dir to know what to hide. Works well: https://gist.github.com/notlaforge/f05bdb9540308a63de90f5f3d69ced95

[ajkessel]

Is there any solution to this now? My antimalware software (Palo Alto Traps) creates a bunch of hidden/system files in directories to check for malware that shouldn't be visible to the user and ls shows them in WSL. I've tried manually adding --ignore options for them but the pattern is not consistent so it's not possible to exclude them all. The gist posted above by @notlaforge no longer exists. Any suggestions?

[ajkessel]

I also took a look at uutils coreutils, which is able to recognize and hide Windows hidden files. But that only has effect in the Windows version of coreutils, not the Linux version which is used by WSL.

One big question is whether the 9p filesystem used by WSL to mount the Windows partition even exposes the metadata necessary to filter on system/hidden files. Does anyone know? If not, how do we ask for that?

[ajkessel]

Adding my comments here since my attempt to open a new issue was closed as a dupe:

Unfortunately this is something that WSL can do since there's no mechanism for us to expose Win32 attributes on Linux mount point.

Is there nowhere a bug on this could be filed? What code needs to be modified to expose those attributes--Windows OS code? 9p filesystem? This is a systemic issue that really should be solved universally rather than with one-off hacks.

If you need to "hide" some files maybe an alias for ls with a custom filter is the easiest way for you.

I don't see a way to do this with files like the antimalware honeypots -- they don't have a predictable filename convention. If there were a way for ls to access the output of windows dir, I guess that could work, but seems awfully inefficient.

[aaronedev]

I ended up writing an ls() function that takes --ignore arguments from dir to know what to hide. Works well: https://gist.github.com/notlaforge/f05bdb9540308a63de90f5f3d69ced95

what happened to it where is it?