Skip to content

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

New issue
New issue
Closed
Closed
Any plans of hiding "Windows hidden files" on WSL bash?#459
Labels
discussionquestion

Description

@mths0x5f
Matheus (mths0x5f)
opened on Jun 1, 2016

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?

Activity

  1. benhillis commented on Jun 1, 2016

    @benhillis
    Ben Hillis (benhillis)
    on Jun 1, 2016
    Member

    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.
  2. Ben Hillis (benhillis)
    added
    question
    discussion
    on Jun 1, 2016

  3. mths0x5f commented on Jun 2, 2016

    @mths0x5f
    Matheus (mths0x5f)
    on Jun 2, 2016
    Author

    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:

    capturar

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

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

    capturar2

    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.

  4. benhillis commented on Jun 2, 2016

    @benhillis
    Ben Hillis (benhillis)
    on Jun 2, 2016
    Member

    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.

  5. niftyhacking commented on Jun 2, 2016

    @niftyhacking
    TomMitchell (niftyhacking)
    on Jun 2, 2016

    On Wed, Jun 1, 2016 at 5:43 PM, Ben Hillis [email protected] 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

  6. shurane commented on Oct 25, 2016

    @shurane
    Ehtesh Choudhury (shurane)
    on Oct 25, 2016

    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.

  7. embray commented on Oct 6, 2017

    @embray
    E. M. Bray (embray)
    on Oct 6, 2017

    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.

  8. therealkenc commented on Jan 11, 2018

    @therealkenc
    therealkenc
    on Jan 11, 2018

    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.

  9. therealkenc
    closed this as completedon Jan 11, 2018

  10. adeolemon commented on Mar 2, 2018

    @adeolemon
    Jordi Bunster (adeolemon)
    on Mar 2, 2018

    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

  11. ajkessel commented on Dec 2, 2023

    @ajkessel
    Adam J. Kessel (ajkessel)
    on Dec 2, 2023

    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?

  12. ajkessel commented on Dec 3, 2023

    @ajkessel
    Adam J. Kessel (ajkessel)
    on Dec 3, 2023

    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?

  13. ajkessel commented on Dec 5, 2023

    @ajkessel
    Adam J. Kessel (ajkessel)
    on Dec 5, 2023

    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.

  14. aaronedev commented on Jul 21, 2024

    @aaronedev
    Aaron (aaronedev)
    on Jul 21, 2024

    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?

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussionquestion

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions