You have to be careful what file extension you would choose on Windows (social.msdn.microsoft.com)

6 points by malkia ↗ HN
It looks like the System Restore would trigger backup of files with certain extensions (574 in count on Vista) every 24 hours.

The full list of extensions is here:

http://msdn.microsoft.com/en-us/library/aa378870.aspx

To me this looks like problem solved completely backwards! Probably when comes to the Windows OS files it makes sense, but not when comes to non-Microsoft Application files.

6 comments

[ 3.9 ms ] story [ 23.0 ms ] thread
Just to clarify: It looks like Windows monitors files with specific extensions (from the article above) the full list consist of 574 extensions on Vista:

http://msdn.microsoft.com/en-us/library/aa378870.aspx

If you have a file with such extension, Windows might do some unexpected I/O (backup) once in 24 hours.

The article points to what the people have found out when they've put .RDB as file extension, which gets monitor, rather than say .DB which is not.

The same story from the SQLite author - http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuningWindow...

"Be VERY, VERY careful what you name your database, especially the extension. For example, if you give all your databases the extension .sdb (SQLite Database, nice name hey? I thought so when I choose it anyway...) you discover that the SDB extension is already associated with APPFIX PACKAGES. Now, here is the cute part, APPFIX is an executable/package that Windows XP recognizes, and it will, (emphasis mine) ADD THE DATABASE TO THE SYSTEM RESTORE FUNCTIONALITY This means, stay with me here, every time you write ANYTHING to the database, the Windows XP system thinks a bloody executable has changed and copies your ENTIRE 800 meg database to the system restore directory.... I recommend something like DB or DAT."

This seems to me to be a rather daft policy for determining which files are sensitive and which aren't. To be sure, I don't know what the right way would be-- I'm guessing something based on paths would work a lot better-- but this solution clearly has serious problems.
Maybe they could've checked only for files coming out of C:\Windows, and some from the "Common Files" of "Program Files" or "Program files (x86)"

I came to appreciate Linux/Mac OSX/FreeBSD style of putting everything in place - /bin/ /usr/sbin/, etc.

With Windows it's just folders everywhere :)

For example the German version of Windows might have C:\Program Files named differently

There is a notion of special directories under Windows, so you can request the Program Files directory without knowing even what drive it would be on. I do realize that a path-based whitelisting approach would introduce unwanted limitations, but considering the cost of false positives, it may be warranted to accept such limitations.
Yet more semantics around extensions? Ugh. I long for the day when we can use metadata instead of doing funny things with names. I fear I'll be waiting a long time...
Doesn't this article explicitly point out a rather horrible Windows flaw, or maybe flaws?

First, having an "extension" as a separate part of the file name has some bad consequences: you have to treat a file name as several parts.

Second, having the file name (.exe, .bat. and some others) make a file executable or not. This seems to have contributed to Windows' malware plague by making it easy to fool people into running things.

Third, confusing the application associated with a file and the file's internal layout seems like an unwarranted step, and this confusion is what the article under discussion deals with, no?