(e-mail address removed) wrote:
MS is developing a scope awareness that would address this, if it
works (I'm not being nasty there; it's a very ambitious thing to try
to do). For example, System Restore manages what is within system
scope and excludes user data and passwords, whereas F.A.S.T. does the
opposite; manages user data only.
Gary Woodruff wrote up F.A.S.T. at
www.aumha.org - have a look there.
My take on data management is a bit different; I plan my data
locations to facilitate backup and data recovery from the outset, as
per
http://users.iafrica.com/c/cq/cquirke/dataman.htm - skip over the
first couple of bits until about 1/3 way down, you get to "User Data
Types", coverage of backup concepts, and "Perils of Restore".
I design the installation around data survivability from the outset,
starting with partitioning. A 2G FAT16 D: user only for small user
data keeps it out of the C: charnel house, and away from incoming
malware, which is on E:; the large cluster size and simple FAT16 file
system makes data recovery fairly easy.
Large data (pictures, music) is located off on E:, and email is split
into messages (safely handled by Eudora) and attachments (exiled to
E
. Because messages (as opposed to attachments) are completely safe
in Eudora, I can include these in the data set, without fear that
embedded malware will pollute this and backups thereof.
Yes, thanks for the good answer. My previous answer to you stands, then.
No, there is no definitive "list" other than the items you already know
about. If you are using OE, I would definitely look at the InsideOE
link. Here it is again:
http://insideoe.tomsterdam.com/ .
MSware is pretty awful when it comes to data management - completely
arbitrary data locations that change with version and whim (often
buried within the OS subtree!), and incoming malware mixed with user
data in solid unscannable .pst and mailbox lumps.
So if using MSware, you have to check:
- "My Documents"
- Windows\My Documents
- Windows\Personal
- Windows\Profiles\{yourname}\My Documents
- "Documents and Settings\{yourname}\My Documents"
- Windows\Application Data
- Windows\Local Settings\Application Data
- Windows\Profiles\{yourname}\etc.etc.
- "Documents and Settings"\{yourname}\Application Data
- "Documents and Settings"\{yourname}\Local Settings\Appl..Data
- Windows\Desktop\My Briefcase
- Windows\Profiles\{yourname}\Desktop\My Briefcase
- "Documents and Settings\{yourname}\Desktop\My Briefcase"
- various AllUsers permutations of above
- sometimes, within "Program Files" subtrees (older Win9x versions)
Some of these locations are easily relocatable, others less so, and
attempts to relocate them may be only partially successful (i.e. a
search of Regedit shows old paths sometimes persist). TweakUI helps.
In XP, user data is supposed to be within "Documents and Settings",
but because XP's inbuilt CD writing locates its buffer in there too,
you can't simply dump the whole subtree on CDR. If you did, you'd
include 256M - 1G+ or Temporary Internet Files garbage, unsolicited
malware recieved by MS Messenger, the Startup groups that may have
live malware within them, etc. It's a mess; you have to dredge the
sludge to pull out your data nuggets, before you can begin the quest
of getting proprietary MSware to actually read or use these.
Some old apps will store their data within the program's subtree, as
per the traditions of the DOS era. Worst-case is where your data
files are mixed up with the program's code files, which you may prefer
to exclude for version or malware-poisoning considerations. This
practice often breaks in XP, which can block writes to Program Files.
If you want to house-train programs to start off in a certain
location, or store data there, how you accomplish this may vary:
- through a Tools, Options "front door"
- through the app remembering where you last File, Open'd or Saved
- by setting working location in program's shortcut properties
- by passing location as command line parameter
- via Win.ini or entries in registry (careful, etc.)
- via the app's private .ini file in Windows base dir
- via app's private .ini in its own dir
- via app's private data files of arbitrary extension
If the last, look for small files with recent "modified" dates
--------------- ----- ---- --- -- - - -
Poor managers blame their fools
