Skip to content

Maybe consider a "visibility" info namespace for "hidden" files #166

Open
@althonos

Description

@althonos

Hi Will,

now that the typing is merged, I was thinking about adding support for a visibility (or hidden) info namespace, with a simple hidden key.

If that does seem like a good idead, I'll start working on a PR.

Concerned filesystems

In the core library, we could probably support:

  • ZipFS (I read somewhere it supports a hidden flag in the external attributes of each entry)
  • OSFS (I'll detail my idea below).

I could also add support for hidden files once the namespace is stabilised to:

  • ISOFS in fs.archive
  • SMBFS in fs.smbfs

Semantics of OSFS

So here's what the situation about hidden files:

  • Windows has a special attribute for hidden files
  • UNIX has no attribute, but files starting with a dot are considered hidden
  • MacOS follow the UNIX convention, but also has the stat.UF_HIDDEN flag to hide files as well

But if we were to support it directly that way, there would be an ambiguity on MacOS where we would not really know if a file is just a dotted file or a dotted file with the UF_HIDDEN flag as well.

So instead, here's what I propose:

  • on Windows, files are hidden only with the hidden flag
  • on MacOS, files are hidden only with the stat.UF_HIDDEN flag
  • on Linux, files are never hidden

and then addind a HideDotted wrapper that:

  • sets hidden to True if the file is a dotted file
  • raises a ValueError when trying to setinfo with the hidden flag set to avoid ambiguity

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions