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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
