| Date: | March 5, 2007 / year-entry #79 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070305-00/?p=27763 |
| Comments: | 55 |
| Summary: | An anonymous commenter suggested that we should give up on "hiding protected operating system files". After all, if we "protect operating system files", that should be enough, shouldn't it? Well, except that some files are still hidden even though they are not protected. For example, your encryption keys are fully accessible to you (after all,... |
An anonymous commenter suggested that we should give up on "hiding protected operating system files". After all, if we "protect operating system files", that should be enough, shouldn't it? Well, except that some files are still hidden even though they are not protected. For example, your encryption keys are fully accessible to you (after all, they're your encryption keys), but they are marked as hidden because if you deleted them, your encrypted files are in trouble. "If visibility itself is core to somebody's security, why not safeguard against a file's enumeration via the ACL?" The purpose of hiding protected system files is to avoid showing users things that would create confusion, would present an attractive nuisance, or would result in "trouble" if they messed with them. Those encryption keys are one example. A user might see them and say, "Huh, what's this? I'm not using it. Let me delete it and free up some disk space." And then boom, they can't recover their encrypted data. One category of files that are an "attractive nuisance" are all those programs in your System32 directory. Feedback from the product support team told us that many users just go into their system directory and double-click everything in it, just to see what happens. If any of those programs happened to do something destructive, you had a very unhappy user on your hands. (So much for the mantra that "nothing you do can physically harm a computer.") We've learned the hard way that none of these programs can do anything dangerous if run with no command line options. For example, An example of files that the user has access to but probably shouldn't be messing with is those |
Comments (55)
Comments are closed. |
Hang on – what are you calling “protected operating system” files here?
“[desktop.ini] files are marked as “protected operating system files” because messing with them changes the plumbing of how Explorer treats those directories.”
Ummmm…..but if users can change them, how are they “protected operating system files”. With particular regards to the “protected” part?
How are you defining protection, if not by an ACL (NTFS) or the System bit (FAT)?
The problem is when there is a conflict between the desire to stop people messing about unknowingly, and allowing the above-average but not expert user to find things.
Think of the grief that is caused by .pst files are hidden by default (apart from the fun that’s caused when you copy them over from CD and they marked read only as a result).
On vista there are even two desktop.ini’s on the desktop. Since I can’t live without seeing the hidden files I have no other choice but to sacrifice two expensive icon space there. There should be a better way customizing folders than littering them with hidden files.
"A user might see them and say, "Huh, what’s this? I’m not using it. Let me delete it and free up some disk space.""
Back in the Windows 3.1 days, I received a call from a friend of mine:
"Hey, Julio. I need more space in my hard disk, so I deleted some useless files. But Windows stopped working — that buggy Windows, always a problem."
"Do you remember which files you deleted?"
"They weren’t my files, so they should be useless. Most of them ended in DLL, I think."
Security != Safety
Protect : Hide :: Security : Safety
Why not use something akin to OS/2’s “extended attributes” in the filesystem itself to hold this customization data?
It seems to me that hiding files is essentially protecting them from stupid people like me who would delete them upon not figuring out what they’re for.
Duh, the command should print a help/usage msg if executed without any parameters.
I would’ve thought that was obvious. :=)
Hiding files to prevent people from deleting them can however turn against you: long ago, in windows 3.11 days, I decided to delete an empty directory as it annoyed me (I didn’t really think through it, I was quite young too). A few days later we discovered that the CD-ROM drive suddenly wasn’t recognized anymore. Turned out that that empty directory wasn’t empty after all.
Ever since I always set windows explorer to show all files.
I think that the source of the confusion here is that what Microsoft really means by "protected" is "should be protected" (which they should), but some people understand that to mean "are protected" (which they aren’t). Maybe verbiage like "important" would have resulted in less confusion?
Personally, I like the concept of system folders better than system files – they’re analogous to the "do not open, no user servicable parts inside" labels on electronics. But what can ya do, what’s done is done.
By the way, there’s a whole thread on shellrevealed.com about hiding desktop.ini
Some folks believe that since desktop.ini is a real file, it should be displayed when the user selects the Show Hidden Files option.
Other people feel desktop.ini should always be hidden – especially on the Desktop – despite the Show Hidden Files.
On Vista, if Show Hidden Files is turned on, then the CD-RW drives will always have a desktop.ini "waiting to be written to CD"
Ever hit Enter by accident in a folder when all its files are selected? WinXP will ask "are you sure you want to open all 1234 files?" but it was loads of fun in earlier Windows.
The lack of a time machine makes it impractical to implement an otherwise ideal solution. ;)
Seriously, both UNIX (all variants) and Windows share two things in common – they’re a product of evolution and not intelligent design, and sacrificing backwards compatability will eliminate adoption of later versions, thus ensuring the perpetuation of decades old design decisions that were the result of hardware limitations that would embarass a wrist watch today. ;)
The whole "desktop.ini" file mess is a compromise to get around the detail that older systems (eg a FAT32 formatted hard drive) won’t really react well to Vista trying to play with "extended attributes", or with ACL based systems. We can complain all we like about the way things work today, but if Windows XP had shipped with a requirement to abandon all previous filesystems and we had to reformat all our hard drives to install, well, then you’ld really have seen some screaming – and much slower adoption.
That said, I’ve never seen a "desktop.ini" file actually on my desktop before, so if Vista actually is displaying it, that’s a definate irritating step backwards.
Maybe go back in time and use the registry instead? Are not other folder customizations "remembered" in the registry?
"Delete those files, and your Fonts folder stops working." Not so.
I cd’d to C:WindowsFonts and used UNIX shell tools to "mv desktop.ini desktop.bak". Lit up WinWord and fonts seemed to work as advertised. The only change was that Explorer let me see the real contents of the Fonts directory, which is what I’d prefer that it do.
Interestingly, cmd.exe seems to be quite twisted when it comes to the Fonts directory. Command completion will work if I type "dir deskt" then press my completion character (TAB) – expands to "desktop.ini" then "not found". Copying desktop.ini to "foo.bak" is likewise "completable" but "not found". So does cmd.exe only recognize .tt? and .fon files in Fonts? No, because renaming "foo.bak" to "foo.fon" is still broken. Love those alternate shells!
I understand ‘hiding’ files to ‘protect’ the user from their own stupidity. Good idea, but it does introduce ‘opportunities’ for untested combinations to fail. In Vista, when Explorer is configured to show all hidden and system files, the desktop.ini files from the desktop directories appear on the real desktop in addition to the normal shortcuts. I guess they didn’t test that combination, but it works correctly in XP.
David, I don’t think the problem with copying desktop.ini is cmd.exe fault. cmd completes the name but "copy" does not want to copy hidden files.
Granted, "copy" is a built-in command. But there are many external commands that don’t work well with hidden files either.
"Delete [desktop.ini], and your Fonts folder stops working"
I don’t think the Fonts folder ever worked properly, to be honest with you. I realised it was broken the first time I put a hard disk from another PC into mine and tried to copy the fonts from one installation to the other… for somebody who wasn’t aware at the time that the shell did virtual directory-like things, it was very confusing.
David Smith, the desktop.ini file is marked with the Hidden attribute, so it is "not found" by standard system utilities like dir and copy that the file is meant to be hidden from. Filename completion does not respect the Hidden and System attributes, so it shows those files just fine. If it didn’t, you wouldn’t be able to use tab completion for the attrib command reliably.
—"Makes a hellova lot more sense than the "hide file extensions for known file types" option that i must remember to disable every time i re-install Windows…"—-
The hide file extensions is the default setting and very much correctly so. If it wasn’t non-tech users would rename the files and change the extension and then find they can’t open them.
Tech users know to disable the setting.
By the way, I’ve never seen a desktop.ini file on the desktop. It’s always in the My Documents folder.
"Hiding and showing is done by IShellFolder::EnumObjects; it’s a property of the folder not of the view."
Well, maybe the implementation should be changed to fit user’s expectations. Figuring how is left as an exercise to the developers.
"Which is a good thing. Otherwise, you change the setting and say, "Hey, that setting has no effect on common dialogs / Internet Explorer / anybody else that re-uses the file browser control."
Uh? Why would you change it in such a broken way? The point is to keep hiding files on the desktop (and possibly a few other places, such as menus), not to hide file everywhere except in the file manager, so it’s the shell views that should be changed.
I don’t see why desktop.ini’s preferred location couldn’t have become an alternate data stream of the directory (rather than a file within the directory), for Vista at least. The shell has already been using ADSes to associate metadata with files and directories. Vista already requires NTFS for the boot volume and depends on NTFS features like reparse points. The old desktop.ini file could still be used for existing (not upgraded) directories and FAT volumes, but only use the ADS form for new folder properties on NTFS. A compatibility shim for the occasional broken app could redirect an open request for desktop.ini to the appropriate stream. This wouldn’t be the first time that such a switch was made.
Desktop.ini is a chunk of metadata about a directory. The problems with it being visible are due to it being incorrectly stored as and treated like a discrete file, when it really shouldn’t be.
Hiding encryptiion keys was probably also a contributing factor to EFS’s initial reputation as "the other recycle bin". Customers were used to reinstalling Windows every so often. It was well-known voodoo to make the OS more responsive. Unfortunately for folks who used EFS, this also resulted in removing those hidden keys in their old profiles. Data loss.
:-(
At least in the case of keys there are risks to hiding them and risks to revealing them. Which strategy is better? I honestly don’t know.
"Huh, what’s this? I’m not using it. Let me delete it and free up some disk space."
Agh, you just reminded me of when I had to support DOS PC users at BT, and everyone had XTree installed (pirate copy, of course), and used to go around ‘cleaning up’ their PC.
The number of people who deleted COMMAND.COM was surprisingly high.
"A "Power User" friend explained to me over IM a few days ago how he was testing the software that comes with Windows. I asked what he meant, and his reply was "Oh, I just wanted to see what all the programs in the Windows, system, and system32 folders do, so I ran them all. Most don’t seem to do anything anymore. Just more proof that M$ windoze is getting more and more bloated.""
Did you stab him with a sharp object? You did stab him, right? And if he survives, tell him he’s not a power user, but a cat that’s in queue to die.
The main problem is that lots of junk accumulates
all over the file system after a while.
Look into %windir% on a typical Windows machine with enabled automatic updates. You’ll see all those %NtUninstallKBxxxxxx$ folders, dated years back. Do users really want to uninstall some update they installed couple of years ago?
Now if you have managed application look into %USERPROFILE%Local SettingsApps that is another elephant bone yard.
The same thing inside the registry hives.
OS does not take care about cleaning all of these.
David Smith: you can use dir /a desktop.ini to show hidden files. For copying, use xcopy /h (I guess this flag wasn’t added to copy because xcopy exists).
But I don’t get why the desktop shows hidden files when the Start Menu doesn’t. It’s not like desktop isn’t already subclassed plenty…
Just have – still don’t see what difference it makes. How can a file be a “protected operating system file” if a regular user can change it? How is that actually “protected”?
As this article is pointing out, hiding is not the same as protection – the two are completely orthogonal. Even if, as per the linked article, you added levels 6 and 7 of the “hidden” attribute, how does that change what a user can *do* to that file if they already know the full path to it?
I guess another way of what I’m trying to ask is – what “protection” is provided to “System” files that are *not* “Hidden”?
Am I making any sense at all?
System files *are* hidden. That’s the protection. It goes clear back to the DOS days, when files with the System bit set were excluded from directory listings. "dir /ah", "dir /as", "dir /ahs" would show what you were missing.
Frankly, it’s about as much protection as i can stand for such things – they’re out of your way, but you can still copy ’em with XCOPY, delete ’em if they get screwed up, edit ’em if you’re bored…
Makes a hellova lot more sense than the "hide file extensions for known file types" option that i must remember to disable every time i re-install Windows…
Raymond > I get that hiding is not the same as protection. That’s clear.
But you say that you hide protected operating system files such as desktop.ini so that users can’t mess with them. I’m trying to figure out how those files count as being “protected” if they *don’t have* an ACL that prevents users from messing with them in the first place.
I agree that the Vista desktop.ini (both of them!) on the desktop is incredibly annoying. I can’t believe that was left there. I know, Raymond, that if you make such a file on XP it will be there; the difference is that XP doesn’t have them there if you don’t put them there. With Vista, they are there already. It makes showing all files/folders useless to those with clean desktops.
Jack:
I’d be extremely miffed if the OS took to "cleaning" locations and deleting files/reigstry that it decided wasn’t important. The system would probably do just as good a job as an inexperienced user at cleaning up because workable artificial intelligence hasn’t been perfected yet.
All of my experience says that the majority of cruft exists there for a reason. Don’t like the cruft? Then fine, remove it, but you lose the right to complain if your system starts to act weirdly or show errors in the future if those system files or registry settings were expected to be there.
My $NTUninstallKB…$ patch folders take up ~170 megabytes of disk space. Compare that to my documents folder that takes up 10 gigabytes of disk space. 1 GB of disk space currently costs approx 40 cents these days. Just as a cost benefit analysis – is it worth leaving the files in place for piece of mind that nothing should break, or delete them to reclaim a bit some space worth just pennies?
It’s good to know that i can click on those prongrams in the Windows dir. ;-) I used to do that back on the Win95 days… :-D
One could find interesting things there, such as the old file manager, a "Win3.1-like" program manager (why???), telnet, mkcompat, regedit…
"The whole "desktop.ini" file mess is a compromise to get around the detail that older systems (eg a FAT32 formatted hard drive) won’t really react well to Vista trying to play with "extended attributes", or with ACL based systems. We can complain all we like about the way things work today, but if Windows XP had shipped with a requirement to abandon all previous filesystems and we had to reformat all our hard drives to install, well, then you’ld really have seen some screaming – and much slower adoption."
In fact, desktop.ini was invented with the Windows Desktop Update in IE4, I think, (I could be wrong), which had to run on 95.
I agree with your conclusion, but sometimes hiding files has unintended consequences.
When XP first came out, I remember there was something of a hubbub about the System Volume Information directory. Not only was it hidden, but it also used ACLs to limit access to SYSTEM. Certain "Power Users" were miffed that they didn’t have access to the directory, and so what conclusion do they reach? Obviously Microsoft is hiding secret information in there! We’d better check it out!
They grant themselves access (proof ACLs do *nothing* to enhance protection) and discover the contents. What a waste of space! This folder is using some 15GB of space! DELETE! A few days later they want/need to try out the neat new¹ System Restore feature. What the crap, it doesn’t even work!? Stupid Microsoft, never gets anything right! I tweak² my system for hours and this is what I get? Impossible!
No matter what you do people will muck with "protected" files. As soon as you strengthen the protection enough to prevent that (if it’s even possible), people cry out about "big brother" and how evil Microsoft is. You just can’t win against a large number of idiots.
By the way, you made me spit Pepsi with "go into their system directory and double-click everything in it". A "Power User" friend explained to me over IM a few days ago how he was testing the software that comes with Windows. I asked what he meant, and his reply was "Oh, I just wanted to see what all the programs in the Windows, system, and system32 folders do, so I ran them all. Most don’t seem to do anything anymore. Just more proof that M$ windoze is getting more and more bloated."
It’s just about too sad to be funny.
¹ WinME doesn’t count
² break
The point here is if a file is hidden and classified as Operating system files everyone will surely think twice before doing anything o it.But working with the hidden operating sysytem files is the most entertaining part for me,particularly hacking system32 folder,SAM,SYSTEM files helped me to learn a lot.
Hiding files by default does make sense, but why should “Show protected operating system files” behave the way it currently does? If I enable it, that’s because I want to see all hidden files *in explorer* (as a file manager), not because I want to clutter my desktop with desktop.ini files.
Actually, what it does is encourage power user to either delete these (with a slight loss of functionality) or accept some hidden file (which is an irritation when you want to explore them).
IMHO, a sane implementation for this option would be to show system files in explorer (as a file manager), but not on the desktop/menus/whatever displayed by the shell (which is explorer, too, of course, but in another mode). I doubt you would find many people actually in favor of the current behavior.
Hm, I thought the desktop on Vista was governed by a desktop manager. Surely it can be tought to ignore desktop.ini’s.
Yes, I too find them very irritating, as well as the fact that my XP on the same machine now has a $Recyclebin folder in each partition even though I turned the recycle bin off in Vista.
What Explorer (and thus the Desktop, etc.) does seems reasonable for general users. For power users who want more control over which files they see then you might want to get a more powerful file manager. (The one I have allows me, if I want, to show all files except a few explicit names or wildcard expressions. I can also define different filename and/or attribute filters for different locations. This is done independently of Explorer so my Desktop doesn’t have to suffer.)
When I switched from Amiga to PC all those years ago I really found myself missing a decent, configurable and powerful file manager. Explorer works but it was and still is very basic and light. (Which may be a good thing in general, but not for me. I’m not saying Explorer is bad; I just want more.)
Back then there were no decent options. The Explorer alternatives completely sucked so I stuck to Explorer and got on with my life. That has changed in the last 5 years or so. There are now several very good file managers for Windows (including my personal preference which is a very well known program from the Amiga days) so if Explorer doesn’t do what you want investigate the alternatives.
We have to keep in mind that MS write software that is used, by default, by millions of people of all computing abilities. Even adding an additional option, or turning a checkbox into a 3-way radio button, could confuse hundreds of thousands of people. Because of that Explorer will probably always be on the simple-but-works side of things with the rest of the market filled by 3rd party options.
If i double click shutdown.exe in the system folder, i expect the system to shutdown.
Totally agreed
Concenring Desktop.ini and the desktip… going slightly off topic:
Half of the posts here would be obsolete if the desktop wouldn’t be some sort of file explorer.
Being aware of the benefits and simplifications that come along with this approach, I’m not so sure if this is really pays off in the end.
Anybody knows how Mac-OS or Unix handle this?
Xavi: OSX and various *nix WMs handle it approximately the same way – there’s a folder called "Desktop" or similar in the user’s home directory that contains the files that are on the desktop. OSX also adds shortcuts to the base directories of various media (hard drives, CDs, USB flash drives, etc, etc) to this.
Vorn
Dazhel:
Very true. However, you can’t add this extra space to the boot partition of a Windows system (which is where the windows directory almost always lives), so it’s a rather moot point. If you need that extra space, you can’t get it, short of reinstalling.
(Yes, there are a few third-party, unsupported utilities that claim to be able to expand the system volume. But it’s unsupported, so most people (including me) aren’t all that comfortable with it. And of course partitions can be expanded if they’re on a dynamic disk, but I’m not sure whether a "normal" partition table can be upgraded to a dynamic one without a reinstall.)
As I recall (and it’s been a very long time), the extended attribute scheme on OS/2 used built-in filesystem support in HPFS (presumably available in NTFS) but used a desktop.ini-like solution on FAT. Which would, if correct, make the same solution feasible here for Windows – you wouldn’t be any worse off than today if you were using FAT32; and you’d be a lot better off if using NTFS.
The OS/2 Extended Attributes were natively supported on HPFS, and continues to be supported on NTFS. They were also supported on FAT systems on OS/2. There was a hidden file at the root of the drive/volume named "EA DATA. SF". The index/offset was maintained in two bytes of the FAT directory entry, starting at offset 20 (0x14). These two bytes are still available on all versions of Windows. Unfortunately, these two bytes have been reused on FAT-32, where they contain the high-order two bytes of the starting cluster number of the file/directory.
To my knowledge, the EAs are not exposed to the WIN32 API. You have to use the Native API functions "NtQueryEaFile()" and "NtSetEaFile()", which are not formerly documented by Microsoft.
I would be curious as to the future of these Native API’s, considering that the OS/2 Subsystem was removed with Windows XP. Too bad MS never made documented WIN 32 interfaces to these, as there may be cases where using EAs are preferable to Alternate Data Streams.
EAs are even better for data hiding than ADSs, since they fly so far below the radar screen. Only backup utilities know about them.
BryanK:
Agreed, reinstallation may be necessary if you absolutely need the space on the boot partition. I’m not all that comfortable with those utilities either. All in all, it’s probably a better solution to buy another hard disk drive.
Raymond, it’s a very interesting subject.
I’ve always wondered about why was decided to use hidden ini files for this.
First, the INI API functions are considered deprecated and we should not use them. Why not use xml or any other (more) portable format?
Second, Windows was designed and recommends applications to use the Registry to store their settings.
Considering that these ini files probably are only useful to Windows Explorer, why aren’t these settings stored in a registry node, for the current logged in user, for example?
These ini files are small but each of them takes 4 KB on the drive. I currently have 112 small desktop.ini files, totaling 17204 bytes but the space used is 458.752 bytes. Yes, I know space is no longer an issue but do these files really need to fragment the driver when all these settings could have been stored in registry or in a single xml/ini file in System32 folder ?
I don’t know, I’m not an expert but it sure looks to me that all this desktop.ini stuff was a feature added without lots of thinking or as a workaround for something.
And I don’t even want to start ranting about Thumbs.db..
Dazhel — that’s probably fine for client machines, yes. It’s not so great a solution for a server (which is what I was thinking about when I wrote the earlier comment, though I didn’t actually say anything about it).
A sister company of ours used to have a machine on our site that ran Server 2k3, on a 4G root partition. It was a 4G root partition because the box was upgraded from NT 4 Server (which didn’t allow a root FS larger than that) without doing a full reinstall. (Our parent company acquired this sister company several years after they had hired some random consultant to do this upgrade.)
Needless to say, Server 2k3 doesn’t run very well on a 4G C drive… we ran out of space several times trying to install patches because of all the NtUninstallXXXXX directories. (Of course having Exchange 2003 installed on the same box didn’t help either, but at least the Exchange databases were on a different partition.)
And of course they don’t use that server anymore, so it’s off and likely to never be turned on again unless they need an old email that they didn’t copy to the replacement. So it’s not even a problem anymore. But it was a pretty large headache for a couple years while it was in use.
(And note, I’m not saying the OS should randomly delete files. It might be nice if the NtUninstall stuff got deleted eventually, but as you say, it’s not really that much space. Unless you’re on a 4G disk that’s almost full and can’t be replaced without either several days of downtime, which the users won’t accept, or a new server box, which the accounting people don’t generally like spending several thousand dollars on without any notice. But hey, whatever.)
Marius: Putting the desktop.ini data into the registry is about the last thing you’d want to do.
For one thing, there’s no limit on the amount of information to store. I could have a desktop.ini for each of 1M directories, which would undoubtedly blow my registry quota.
Another reason is that you want the customization to move with the folder. I shouldn’t lose my customizations just because I rename a folder or move it to a different parent, or even a different computer. And renaming a folder would orphan all of the data in the registry under its name.
Similarly, an administrator should be able to set the customizations for folders on a file server. A user shouldn’t have to make his own customizations every time he maps a share to a different drive letter.
While I do like the idea of using EAs or ADs to store the data, it would be extremely difficult to get your customizations when copying a folder to a CD, zipping it up, or transferring it via FTP.
Thank you Gabe. It makes sense what you say.
However, it still makes me think.. How often do you copy or move folders like your My Documents , Windows, System32 or Program Files folder?
I’m using Windows operating systems since Windows 3.0 but never in my life I needed those Desktop.ini or Thumbs.db files. I hardly ever use Windows Explorer for a fact, 99.99 % of the time I use Total Commander which doesn’t care about those files.
You’re right, storing settings in registry for 1M folders isn’t right, but would you accept having 1M x 1 KB files on your drive taking up about 4 times as much space because the smallest size a file can be is usually 4 KB ?
My solution would probably be creating a database for these settings and an API that applications would be able to use and offer the choice of transferring these files along with the rest of the files in a folder. There are more advanced problems with the file system such as applications that do not copy the alternate file streams of a file and this didn’t force Windows and Microsoft to create workarounds.
Thursday, March 08, 2007 4:42 AM by Marius
OK I’ll do that for you.
Someone (I don’t know who) used Windows Explorer to take a look at a folder on a file server. The folder was ready to be zipped and sent off for its contents to be put into ROM on hundreds of thousands of devices. Well, it was, it really was, until someone used Windows Explorer to take a last look at it. The person didn’t notice that Windows Explorer added an unwanted thumbs.db, which almost got sent off to be put into ROM on hundreds of thousands of devices. Fortunately my last look came later.
Thursday, March 08, 2007 10:25 AM by BryanK
Actually NT4 did allow a root FS larger than that, it just couldn’t create a larger one on the fly during installation. You could create a larger partition by using Partition Magic, or attach the drive to an existing NT4 machine, etc. Then tell the NT4 installer to install into the existing partition without changing it.
If you had a BIOS with inadequate INT13 extensions then you had to use additional trickery or you’d still get hit at the 7.8GB mark.
Has it ever occured to anyone that operating system should keep its important files in its own directory???
Current system is a mess. Protecting files by hiding them is the worst solution. I really grew up to hate desktop.ini and thumbs.db because people tend to archive them using WinZIP or WinRAR together with files they send me. Arcive utility writers had to resort to implementing workarounds for this nonsense by allowing you to specify list of files you don’t want extracted.
ACLs are also useless because they can be manipulated directly by the admin.
My point is — if it is a system file and if it is crucial for correct functioning, then only system itself should see it. Period.
Fortunately that is not hard to do — filesystem filter driver and a list of files and folders to be filtered out from display. If you believe that it poses security risks (rootkits) then make every change to that list visible in event log and if you decide to allow third party developers to use the feature, then also allow users to allow or deny modifications of that list.
Oh really; that’s good to know. Well, maybe not "good", since I’ll likely never use it, but at least "interesting". :-)
I agree with Foolhardy. If an ntfs volume, store this stuff in a stream in the directory.
Streams get lost when the file is archived, moved to FAT16/FAT32 volume, or burned onto a CD/DVD.