I am no Windows expert, and untested, but combining some sources gets me:
To read Mac OS Extended (aka HFS+) disks on Windows, according to Wikipedia:
HFSExplorer is an application for viewing and extracting files from an HFS+ volume (Mac OS Extended) or an HFSX volume (Mac OS Extended, Case-sensitive) located either on a physical disk, on a .dmg
disk image, or in a raw file system dump.
It seems that an Ubuntu Live CD also has support for HFS+.
Once you have access to the drive you will see a structure of folders. This screenshot from the HFSExplorer web site shows such Time Machine backup folder:
Browsing to Backups.backupd/<computer name>/Latest
should get you your latest backup. Your documents will be in the sub folder <hard disk name>/Users/<user name>
.
And even though there's no need to make any changes to the disk: remember to always use something "Safely remove hardware" before unplugging the disk from Windows (just like you would "eject" it on a Mac).
The issue here is that Finder implements special handling of files restored from Time Machine to preserve all their permissions, which failed for files owned by the current user's account, but not a group he's a member of.
Usually, when copying files using cp
, their attributes aren't retained. This can be changed using the -p
option.
-p Cause cp to preserve the following attributes of each source file in the copy: modification time, access time, file flags, file mode, user ID, and group ID, as allowed by permissions. Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks, will also be preserved.
In both cases, you either copy all or none or these metadata. cp
is clever enough to restore them only after all contained files have been processed ([source, see near If -p is in effect, set all the attributes
).
If you don't have root permissions, ownership is not retained. The reason for this is that only root can make files owned by users not him and by groups he's not a member of.
To make Time Machine backups viewable but otherwise immutable in Finder, they are protected by Access Control Lists denying all users all modification permissions.
0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
Since other attributes (other ACLs, extended attributes, file dates and permissions) should be retained when restoring from backup, special handling of these folders is required in Finder. It must remove a specific ACL entry, but retain everything else.
Additionally, Apple apparently wants Finder to retain all ownership information when copying files and directories from backup. This includes the group membership.
If your account is not the owner of the directories in question, Finder requests an administrator password and hands the copying off to its elevated privileges helper program Locum. This does not happen when you are the owner of a file in the backup set.
Now, one of the following cases happens:
- You are not the owner of the file: Finder asks for your password, Locum restores all permissions just as in the backup.
- You are the owner and a member of the file's group: Finder copies the file over and restores the group.
- You are the owner but not a member of the file's group: Finder copies the file over and fails to restore its group.
It's like it's trying to chown username:groupname
the file, and prints an error if it fails — which it does if you're neither root
(sudo
) nor username
and a member of groupname
.
It behaves slightly differently if you're not copying folders, but files: While file ownership is retained, group membership is discarded if you're not a member of the group. This is what you saw when only copying a single file.
The obvious solutions to this problem:
- Prevent file ownerships that cause restoration to fail (i.e. owned by you and a group you're not a member of — most of the time, this isn't useful anyway)
- Make yourself a member of that particular group at least temporarily. Unfortunately I wasn't able to do this using
dscl
from the command line in a way that had an effect without logout or restart. Another side effect is that with wheel
, you might run into problems with permissions depending on your system configuration.
Best Answer
EDIT: According to @Ken Arnold in the other answer to this question, this technique will not work due to Time Machine backups being locked down by ACLs. I can't guarantee this, as I haven't checked it, but it's worth noting before you proceed with this answer. :ENDEDIT
Based on a quick look at my Time Machine backup, all you should need to do is take ownership of the files.
If you navigate to your Backups.backupdb, you should see a folder with the name of your machine on it. If you cd into that folder, you will find a long list of folders that correspond to every backup Time Machine has made.
Due to the way Time Machine works, each of these folders contains a complete representation of the state of your machine at that particular point in time. To get full permissions to read/write etc, you should simply take ownership of one of the folders.
Suppose you just want the latest backup folder, which OS X has helpfully created a symlink for. In that case, the sequence of commands (with a generic username on my machine) would be:
An alternative would be to simply take ownership of the entire backup history, in which case you would use:
An alternative would be to enable the root account and from there you can mess around with the files to your heart's content. Don't forget to disable root once you're done, and for the love of all that is holy don't ever type
rm /
.PLEASE READ:
I haven't tested this on my own Time Machine backup, as it's pretty extensive at this point and I'm quite attached to it. However, it's possible that some issues might occur with the nature of the Time Machine backup. In OS X, Time Machine uses hardlinks to reproduce unchanged files and directories. This means that each file contains the entire filesystem as it was at that point in time. However, OS X does not allow hardlinking to directories outside of Time Machine. I can't honestly say what affect this will have: possibly none, but I can't rule out unexpected behaviour. Just a warning.