Why are hidden files with a leading tilde treated as super-hidden? | Hacker News Reader

Why are hidden files with a leading tilde treated as super-hidden?

blogs.msdn.microsoft.com

91 pointsabhinickz32 comments

Open articleView on HN

Violation of orthogonality of design. http://www.catb.org/esr/writings/taoup/html/ch04s02.html#ort...

Or simply a "simple is better than complex" from PEP-20 https://www.python.org/dev/peps/pep-0020/

Also, "Explicit is better than implicit." and "Special cases aren't special enough to break the rules.", etc.

Doesn't apply here: it's not a designed system, it's a pile of hacks.

Doesn't matter; it's what shipped, and so is a system in spite of its quality or lack thereof.

There's no problem pointing out a non-computer as not turing complete if it was shipped and sold as a computer.

That's why you have to disable "Hide protected operating system files" in order to see them.

One of the settings, along with hiding the file extensions, that I always disable without exception.

Legacy compatibility reasons, I presume. I know this worked to super-hide files with NT 3.5x/4 and Win-9x or used when copying files by those OS's. And I'm fairly certain that it existed for "temporary" files with MS-DOS 6.x and 5.x too, maybe even earlier version. Are there any MS-DOS 2.x / pre lan-manager pros on HN who know how long this has been around?

I have an old MSDOS 2.0 manual.

~ is listed as an acceptable character for filenames.

Here are some photos of various pages:

http://imgur.com/a/E952T

One might argue that the correct fix is to remove the concept of super-hidden files entirely. For backwards compatibility, just never report that a file is super-hidden.

Normal users don't see hidden files, so normal users are served well. Users who want to see the complete list of files (to clean up garbage, notice crap left behind by malware, fix problems caused by leftover malware, etc) probably want to see files that start with ~.

Alternatively, the options could be "hide hidden files", "show hidden files but not protected operating system files", and "show all files, even protected operating system files", rather than having separate, confusing controls.

Okay, so who decided on that? Is it a PM or a developer? What's their reasons and why didn't they document it?

Do I have other "invisible" files around that I can't see?

This particular behavior sounds more like a bug than an explicit design decision.

Do I have other "invisible" files around that I can't see?

Most system files in Windows are hidden. I think it's an effort to prevent users from deleting some important system file, either accidentally or because they read on some website that it's a virus.

Or the ever popular habit of deleting large unknown files to free up space on disk.

Backwards compatibility.

Older versions of the Office suite used ~ files as locks. New versions flag those same files as hidden and system, so Microsoft hacked in a compatibility fix for old versions of Office to mark all ~ files similarly automagically.

I love all the comments here about "how could this be?"

Repeat after me...There is no magic. There is no perfect.

This software was used by hundreds of millions, if not billions, of people. They got work done with it. Think your favorite pile of C code is "more correct" or "more sublime"? Maybe. By many measures of successful that doesn't matter. And that's why those "it will be perfect this time" rewrites of UNIX/Linux aren't in use and Unix/Linux is.

By many measures of correct, success also doesn't matter. Let's remember how many flaws were the cause of time, money, mood loss of many people. How do you know which is more important at the level of something like an OS?

Btw, the time when legacy support was crucial is long gone. App stores and automatic updates will make it absolutely transparent in few decades. Windows is probably the last OS where you download and execute random ancient chunks from the raw internet -- nothing to be proud of.

Interesting personification of Explorer. One might think it were a person the way it is described.

http://catb.org/jargon/html/anthropomorphization.html

So, how do we fix it?

> This problem was fixed in Windows 8 as a side-effect of a re-write of the way the shell copy engine copies files. The shell now uses the CopyFile2 function to copy files, relying on the kernel function to do the heavy lifting, and using the callback function to monitor progress and possibly cancel the operation. The kernel function doesn't know about these mysterious shell item IDs. All it knows how to do is copy files, and it obtains the attributes directly from the source file, which as we recall is marked hidden but not system.

Yeah, that sounds better.

You use Linux :-D

How could this be in the core of an OPERATING SYSTEM? At one of the largest software manufacturers in the world? I legitimately do not understand.

Not to be too snarky, but tons of other operating systems have these kinds of "features". The most prominent example is in macOS and Linux with file names starting with a dot being hidden by default.

Yes, but the reason for that convention is just to avoid clutter in the output of ls. It's not to prevent users from deleting files that they shouldn't -- file system permissions, and not logging in as "root" all the time, are the correct way to handle that.

Hiding files starting with a dot is just a cosmetic, view level implementation. This article shows that Windows had coupled this behavior directly to system level file flags.

> Hiding files starting with a dot is just a cosmetic, view level implementation.

Is it? [0]

[0]: https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9...

This is also just a cosmetic, view level implementation in Explorer (complete with a bug, also in Explorer). In fact, the fix was to use kernel fs functions directly.

> cosmetic, view level implementation

Sort of. The kernel doesn't treat it special but the OS does.

Any POSIX compliant shell won't include dot files for a single wildcard.

E.g. rm -fr * doesn't empty the current directory.

The Unix (Linux and Mac inherit this) idea of a leading dot = hidden is almost certainly from the days before file attributes were even invented (err available on Unix). Don't quote me on that and I can't be arsed to do the research but it certainly sounds possible!

In Linux it is a bit of an arse. My home directory looks absolutely rubbish when I view it on a Windows box, which I do with monotonous regularity when fixing the bloody things (Windows boxes that is.)

I suppose that could be, I don't know either. I think it's more likely from the early days where users were interacting over slow teletypes or terminals, and having a convention that hid rarely-interesting files by default was more efficient.

It was a bug in ls. The intent was to hide only "." and "..".

https://unix.stackexchange.com/questions/88875/why-are-filen...

It started out as unintended behavior of some code in "ls" which was put in to skip "." and ".." when printing directory listings.

https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp

The concept of a "hidden file" was an accidental invention.

To be fair, it's not in the core, it's in the shell. The shell treats files that have FILE_ATTRIBUTE_HIDDEN and start with a ~ as if they also had FILE_ATTRIBUTE_SYSTEM, but this only affects the shell. It doesn't leak to other programs that use the filesystem APIs directly. The shell has always had a different, more user-oriented view on the filesystem. It also does other user-oriented things, like replacing some filesystem names with display names (eg. C:\ -> Local Disk (C:),) letting you browse things that aren't filesystem objects, like remote FTP shares and files inside .zip archives, and synthesizing folders that don't really exist like This PC/My Computer, the Desktop, Recycle Bin and Libraries.

Reply on news.ycombinator.com