10.5: Reconnect Time Machine backup after drive swap

This hint is inspired by and uses tricks introduced by the hint Repair Time Machine after logic board changes, and is used for a similar purpose. In this case, I used this hint to re-connect Time Machine after migrating a partition from one hard disk to another one. I know it works with an image copy of your partition.

DISCLAIMER: Do this at your own risk! Have a backup of at least your most important files on a separate medium! Do not attempt this if you are uncertain about any of the consequences or circumstances here! There are no guarantees that the following will work for you!

Start from a different disk if you want to copy the system partition (use the System DVD if necessary). In Disk Utility, select the target disk (which must have been partitioned so your Mac can actually boot from it!), click Restore, drag the target partition to the Target field, and the old partition to the Source field. Don't forget to select Erase Destination, or it will in fact just make a file copy. Progress will then be shown as copying blocks instead of copying files.

The copy will be almost identical to the original -- only the drive ID (UUID) will be different, and that is why Time Machine would try to make a complete backup if we didn't do something to prevent it. I have not tested whether a mere file copy of a partition can be re-connected successfully so that only incremental backups are made. It does seem to work with an image copy, though.

After the image is done, remove the old drive/partition, or otherwise disable it, so that you're not confused by its presence -- all commands that follow will refer only to the new partition, and a change will be made only to a folder in the Time Machine backup.

Important: First, disable Time Machine.

Next, open Disk Utility, select your new partition and press Command-I to display the partition's information. You will need the Universal Unique Identifier value; select it with the mouse, copy it, and paste it somewhere for use later. Then open Terminal and go to the last Time Machine snapshot:

$ cd /Volumes/my_backup/Backups.backupdb/my_mac/Latest

Replace /Volumes/my_backup with the full path to your (new) Time Machine drive/partition, and replace my_mac with the name of your Mac as shown on the Time Machine drive. This directory will hold one (or more) folders, each named after one of your drives or partitions. For safekeeping, display the old partition's UUID before you do anything else -- this is the one that Time Machine has attached to your backups:

$ sudo xattr -p com.apple.backupd.SnapshotVolumeUUID my_partition

Replace my_partition with the name of the partition that you'll be swapping the UUIDs on. The command will print out a UUID, just like the one displayed in Disk Utility above. If the UUIDs are identical (which they won't be, yet), Time Machine will make an incremental backup; If they don't match, it will back up the entire partition again.

So if you are really, really certain that your new partition is in fact just a copy of your original partition, and you want Time Machine continuity, you can reconnect the last backup of your old partition to your new partition by overwriting exactly that UUID with the one of the new partition.

First temporarily disable ACL protection for the backup drive:

$ sudo fsaclctl -p /Volumes/my_backup -d

Whatever you do, do not forget the matching command below to re-enable it again!

Next, and this is the critical step, overwrite the UUID with the UUID you have copied from Disk Utility above (the UUID is represented by the X's in this example):

$ sudo xattr -w com.apple.backupd.SnapshotVolumeUUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX my_partition

Now re-enable ACL protection for the backup drive:

$ sudo fsaclctl -p /Volumes/my_backup -e

Now you can re-enable Time Machine, and it should recognize your new partition as the same as your old one, and only make an incremental backup. When the motherboard of your Mac has changed, proceed as described in the original Repair Time Machine after logic board changes hint.

[robg adds: I haven't tested all of this hint, only the bit about reading the UUIDs off the backup drive, which worked as described.]

From our Sponsor...

The macosxhints Poll

What version of OS X are you running as your main OS?

10.5: Reconnect Time Machine backup after drive swap | 45 comments | Create New Account

Click here to return to the '10.5: Reconnect Time Machine backup after drive swap' hint

The following comments are owned by whomever posted them. This site is not responsible for what they say.

10.5: Reconnect Time Machine backup after drive swap
Authored by: Soybean on Thu, Feb 19 2009 at 9:09AM PST

Interesting. I simply cloned my hard drive (using Carbon Copy Cloner) when I was upgrading my MacBook Pro from a 250GB to a 500GB drive. Time Machine performed an incremental backup without any issue (other than my having to unplug and replug the drive into my Airport Express Base Station).

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Thu, Feb 19 2009 at 9:22AM PST

You probably had it make an identical disk copy block-by-block which does indeed keep the connection to the backup but it could produce problems when both drives are present at the same time or alternatingly while the "hinted" solution still keeps them apart properly.

If it's just about 1:1 replacement with immediate removal / erasing of the old partition, that is certainly an option if you're really careful. It would get problematic when you chose to swap the drives again later on — Time Machine would then "back up" the difference between the newer drive and the older one, probably "removing" all the files in the newer backup which you had created since the switch to the new drive. And Jobs only knows what would happen if both drives were present at the same time!

In my case I simply wasn't inclined to spend another several hours on a new copy of the disk after I had already been through it with Disk Utility.

There just had to be another way around the problem, and indeed there seems to be! ;-)

---
There are no problems...

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Thu, Feb 19 2009 at 9:41AM PST

I forgot to add: The "hinted" solution probably also works on a file copy of a partition, not just on a block copy. I have not tried that one out myself, but from the way things work it is conceivable that even a file-copied partition could be re-connected which would certainly not work otherwise.

10.5: Reconnect Time Machine backup after drive swap
Authored by: wch on Mon, Mar 2 2009 at 7:28PM PST

I just did a file copy of a partition using Carbon Copy Cloner, and the new partition received a new UUID, so I used the hint above. It seems to have worked -- the first backup size is only 60.7MB, after maybe 25 minutes of "preparing". The backup is running now, although it seems to be going quite slowly; after about 10 minutes, 5.5MB has been backed up. Hopefully things will be faster the next time around....

10.5: Reconnect Time Machine backup after drive swap
Authored by: wch on Mon, Mar 2 2009 at 9:25PM PST

Update to my previous post: subsequent backups seem to run at normal speed.

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Tue, Mar 10 2009 at 9:06PM PDT

That is because OS X keeps a record of files which have been changed recently, but this record is not infinite.

Time Machine uses this record if it can — but when it suspects that the record does not contain all the changes made since the last backup it will do a "deep traversal", basically looking at every file on both disks and checking whether it needs to be backed up or not.

After you've made your copy, the change record on the copy was not deemed consistent and complete, so it took the long road on the first backup.

After that, however, Time Machine was back in sync and on the following backup it could use the change record which was much faster.

If you should have a long gap between subsequent backups, Time Machine may still revert back to deep traversal, but that is normal and will "fix" itself automatically when the backups are closer together again.

---
There are no problems...

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Thu, Feb 19 2009 at 11:07PM PST

In the comments of the aforementioned hint, 10.5: Repair Time Machine after logic board changes, I wrote about the value of the cookie which has to be the same on both drives, and should match the contents of the file /var/db/.TimeMachine.Cookie on your Mac. Maybe the UUIDs are important too, but in my case I simply used Finder to copy the sparse bundle and the hidden cookie file, and that was it.

Note that my set up uses a sparse bundle on USB drives connected to a Mac Mini, which are used for my MacBook Time Machine -- I never tried with attaching the drives directly to the MacBook.

If these cookies do not match then the logs will show Volume at path /Volumes/TM does not appear to be the correct backup volume for this computer. (Cookies do not match), so for whoever sees that message: for you the UUIDs are not important (and fixing those might not help); see the earlier hint.

10.5: Use multiple drives for Time Machine backups
Authored by: palahala on Thu, Feb 19 2009 at 11:17PM PST

By the way: I swap those two drives all the time; I use Time Machine with multiple disks. No problems (but, again: things may be different when connecting the drives directly to your Mac -- post your results here!).

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Fri, Feb 20 2009 at 2:03AM PST

You seem to refer to a different situation.

Basically I can think of three different issues here:

- Swapping the motherboard (that was your hint)

- Swapping the backup disks (that seems to be what you're referring to above)

- Swapping the original disks (that is my hint above)

10.5: Reconnect Time Machine backup after drive swap
Authored by: bll on Fri, Feb 20 2009 at 4:39AM PST

I faced the same problem by just reinstalling the system on the same drive, after reformating the drive. Reformating updated the UUID and Time Machine wanted to redo a full copy. By using the same trick (shame on me, I did not publish it), I was able to get the intended behavior.

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Fri, Feb 20 2009 at 5:47AM PST

Well, at least that's an independent confirmation! ;-)

---
There are no problems...

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Fri, Feb 20 2009 at 12:19PM PST

Aha, indeed it was not clear to me that you swapped the (source) disks in your Mac that uses Time Machine (not the target disks that you use to store your Time Machine backup).

Now that you explained about this UUID, I'd imagine that the content of /var/db/.TimeMachine.Cookie might somehow be related to the UUID of the drive that is the source for the backup. On the other hand, in the Unix world, I'd expect Time Machine to back up file systems that are actually located on multiple drives (like /home could be on some other drive than the other folders). If that were true then the UUID of a single partition should not matter. But given your hint, I assume that Time Machine in fact does rely on that UUID, and thus cannot create backups of file systems that use multiple drives...

Just for the record: the 10.5: Repair Time Machine after logic board changes hint was not mine; I just commented on it.

10.5: Reconnect Time Machine backup after drive swap
Authored by: only_solutions on Fri, Feb 20 2009 at 10:07PM PST

palahala: Aha, indeed it was not clear to me that you swapped the (source) disks in your Mac that uses Time Machine

Okay.

palahala: Now that you explained about this UUID, I'd imagine that the content of /var/db/.TimeMachine.Cookie might somehow be related to the UUID of the drive that is the source for the backup.

That sounds plausible... It is probably used to detect the connection of the currently selected backup drive ("Change Disk" in Time Machine preferences probably re-sets it).

palahala: On the other hand, in the Unix world, I'd expect Time Machine to back up file systems that are actually located on multiple drives (like /home could be on some other drive than the other folders). If that were true then the UUID of a single partition should not matter. But given your hint, I assume that Time Machine in fact does rely on that UUID, and thus cannot create backups of file systems that use multiple drives...

Or at least not directly... especially when I think of FileVault I would expect that that is intentional. But since Time Machine is ultimately based on a souped-up version of rsync, maybe a closer look to its manual can give some information about that aspect.

And with the imminent introduction of ZFS the entire Time Machine mechanism may get a significant overhaul anyway.

palahala: Just for the record: the 10.5: Repair Time Machine after logic board changes hint was not mine; I just commented on it.

Yeah, I've just noticed that after posting. :-)

Not Mac-like...
Authored by: rgray on Fri, Feb 20 2009 at 6:42AM PST

It seems to me that this TM problem and the solution(s) are very unMac-like.. and a flaw in the whole TM concept that makes TM difficult for the less technically astute users. The problem stands in gross contrast to the way TM works generally to find and restore files. What would be wrong with having TM work so that one could just navigate to the desired 'archive' and double click to use??? Or am I missing something. The way it is most of my clients would be lost if a drive or a mobo was changed and that does not seem fair - besides as I said before it stands in gross contrast to the rest of the Mac experience.

Not Mac-like...
Authored by: only_solutions on Fri, Feb 20 2009 at 7:53AM PST

I can see where you're coming from, but Apple apparently went the way of the lowest risk (at least on the face of it).

When you're presenting a new harddisk to Time Machine, it is treated like a different harddisk. If you could assign it manually to an older backup you could wreak real havoc in case that assignment was really a mistake.

So they apparently erred on the side of caution, restricting the possibilities to accidentally mash together what's in fact not the same thing. In my case I was certain enough that it should work okay and I assumed the responsibility for any undesirable outcome; But many users would block the support hotline and/or threaten to sue because of data that was at least apparently lost to them.

On the other hand I would have lost older copies on my TM backup drive if I had just let it make another entire backup instead of a compact incremental one. Neither solution is perfect, both have their flaws and risks.

---
There are no problems...

Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: palahala on Sat, Feb 21 2009 at 1:11AM PST

I wonder if Time Machine will continue making incremental backups when restoring a backup to a new drive. If true, then for those who are still planning to swap the drive of their Mac for another drive: maybe a full system restore from Time Machine to the new disk will save you from having to change the UUID.

And when doing a full restore to a new disk, I am curious if Time Machine will then change the UUID of the target disk (which would not make it very unique then...) or on the backup disk.

Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: only_solutions on Sat, Feb 21 2009 at 1:33AM PST

According to Apple Support (yes, I actually asked them about it! ;-) ) a restore from a Time Machine backup does unfortunately result in a completely new full backup being made right again which is obviously stupid, but consistent with the way the mechanism seems to work.

I'm with you in that, of course: They should either adapt the UUID in the backup or have a separate mechanism for this purpose to avoid such a pointless double backup. It actually reduces data security because the pointless double backup pushes older backups off the disk if there's not enough space plus of course it stresses both the original and the backup harddisks much more than necessary.

On the other hand having multiple drives with identical UUIDs looks like a really bad idea – too many potentially serious consequences could ensue.

So if this information is in fact true (can anybody attest to that who has made a Time Machine restore and tried to resume Time Machine backups to the same drive?), this hint here could be very useful in that case as well.

Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: palahala on Sun, Feb 22 2009 at 1:54AM PST

Giving it some more thought, I can image some people might restore a backup on another drive just for testing or whatever. One indeed does not want this to result in changing some UUID in the backup, as that would render that backup useless for the original drive.

So I guess your solution is better than having Time Machine decide when to make some changes: only people who know for sure they want the UUID of the backup changed will now be able to do so, and those will understand that removing that sticker will void their warranty ;-)

Many thanks for the info!

Changing sytem disk: restore from Time Machine rather than full copy?
Authored by: only_solutions on Sun, Feb 22 2009 at 6:34AM PST

You are probably right...!

And you're welcome; Of course I owe most of the thanks to this site and to other contributors. :-)

---
There are no problems...

10.5: Reconnect Time Machine backup after drive swap
Authored by: logo on Wed, Mar 11 2009 at 1:48PM PDT

Hint is really appreciated.

Worked exactly as described after my drive swap and copy from old to new drive with disk util.

Thanks a lot.

Only worked for me after a small modification
Authored by: yumbrad on Thu, Mar 12 2009 at 12:05AM PDT

I'm not sure why this was needed, since it really should be basing it's work on the "Latest" backup (which I verified was pointing at the last date-stamped dir in the TM bundle), but I needed an alternate step. I tried the tip as is initially, and it failed with not enough room, as from console I saw it requested 300GB (all my files). Instead of the one "sudo xattr -w" step, I had to do this:

for d in ../*; do sudo xattr -p com.apple.backupd.SnapshotVolumeUUID $d/Macintosh HD/ ; done

After this, it still had to do a "deep traversal" because the "Event store UUIDs don't match for volume", but once it did, instead of the full 300GB, it only requested 600MB or so - back to incremental backup!

[ Reply to This | # ]

Only worked for me after a small modification
Authored by: only_solutions on Thu, Mar 12 2009 at 1:32PM PDT

That is a bit strange, since your command only displays the IDs, but it does not change them.

Maybe you just hadn't switched Time Machine off before making the change, so it might have cached the old ID and just took a while until re-reading it eventually.

But anyway, good to hear the hint has been of use to you. :-)

Only worked for me after a small modification
Authored by: yumbrad on Thu, Mar 12 2009 at 10:25PM PDT

Whoops! Sorry - I pasted in what I used to display the UUIDs before and after. The step I replaced looked like this of course:

for d in ../*; do xattr -w com.apple.backupd.SnapshotVolumeUUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX d$/my_partition; done

And yes, thank you very much for posting this tip - quite serendipitous as I just upgraded my iMac drive from 500gb to 1.5tb. So now I'm using three non-Apple-officially-supported methods that work great together - your seamless drive upgrade tip, the one to stick my time machine backup on an "unsupported" network share (Unraid server), and one to manually limit the size of that TM bundle... Pretty soon I'll think of hdiutil as a good old friend, and won't think of these as unsupported workarounds :) ... MacOS is my third OS to learn after DOSWindows and linux, and I'm liking it!

[ Reply to This | # ]

Only worked for me after a small modification
Authored by: only_solutions on Fri, Mar 13 2009 at 4:56PM PDT

Ah, that's more like it. ;-)
I still can't say why you needed to do that.

Undocumented procedures can be fun... as long as one never forgets that greater power comes with greater responsibility...! 8-)

---
There are no problems...

10.5: Reconnect Time Machine backup after drive swap
Authored by: alexliz on Mon, May 25 2009 at 4:55AM PDT

I get stuck at the step which displays the old UUID. All I get is a complaint from Terminal, "No such xattr: com.apple.backupd.SnapshotVolumeUUID"

I've tried different variations of what I understand the command might be, all to no avail. What could I be doing wrong?

Many thanks!

---
Alex

10.5: Reconnect Time Machine backup after drive swap
Authored by: TigerKR on Mon, Jun 8 2009 at 1:09PM PDT

This is a great hint. I was able to use this hint to have TM continue to backup an external drive that I cloned to a new external drive (to get a larger capacity). Thank you!

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Mon, Jun 8 2009 at 1:38PM PDT

Good, though I guess there are easier guides to achieve just that, like A Bigger Time Machine without Changing History.

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Wed, Jun 10 2009 at 2:38AM PDT

More details on Time Machine's extended attributes such as com.apple.backupd.SnapshotVolumeFSEventStoreUUID, com.apple.backupd.SnapshotVolumeLastFSEventID and com.apple.backupd.SnapshotVolumeUUID at Quarter Life Crisis: X.5 Time Machine.

10.5: Reconnect Time Machine backup after drive swap
Authored by: wjwt on Thu, Jun 11 2009 at 2:27AM PDT

This is a great hint, works perfectly. Replaced the original 40GB hard drive (!) in an old G4 Quicksilver with a new 80GB drive, and TM wanted to back up 31GB (i.e. the entire contents of the drive). Used this hint exactly as described, and the backup dropped to 2.7GB. As another poster noted, took a long time "Preparing backup..." the first time, but subsequent backups are back to normal. Excellent hint -- thank you. I agree that it's surprising that Apple hasn't provided a more user-friendly way of doing this -- replacing original drives isn't uncommon!

No need for this!
Authored by: sunsetchaser on Thu, Jun 11 2009 at 7:30AM PDT

I just spent a couple of hours banging my head against the wall because I couldn't believe Time Machine would handle a new drive so poorly!

Then, on a whim, I restarted my Time Capsule. Lo and behold, all my old backups appeared when I entered Time Machine. Backup status was missing -- no information about oldest backup, latest backup -- so I clicked "Back Up Now", and waiting 15 minutes while it said "Preparing backup". It did then start creating a new backup in the same location as the old backups, and entering Time Machine still showed all the old backups.

*However*, it said the size of the backup to be done was 99 GB -- about 25 GB less than the actual amount of data on my hard drive. Maybe that's everything but the OS itself? Who knows, but...

Bottom line is, no monkeying around in Terminal is necessary if all you care about is access to your old backups, *and* if you have plenty of space on your Time Machine drive. Looks like a simple restart won't save you from having to do another almost-full backup though.

10.5: Reconnect Time Machine backup after drive swap
Authored by: markauk on Tue, Jun 16 2009 at 5:36PM PDT

Thanks only_solutions for the tip and yumbrad for the modification, which I needed to make it work for me. I think you have a small typo in what you suggest, though, it should be:-

for d in ../*; do xattr -w com.apple.backupd.SnapshotVolumeUUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX $d/my_partition; done

At least, I had to change d$ to $d to make it work for me.

10.5: Reconnect Time Machine backup after drive swap
Authored by: PeeWee on Wed, Jul 15 2009 at 7:06AM PDT

Fantastic! Although I'm not a Terminal pro at all, I managed to reconnect my backup with this guide. Since I moved my Data from one MacBook Pro to a new one using Migration Manager, I did the logic board / MAC re-pairing in the same time.

Just a notice about how long the first backup after the action took: It was remarkable 36 hours in my case to write about 8 GB, but extremely slowly. Believing something went wrong, I was close to abandon it, but resisted. Since then all further backups work as fast as usual.

Thanks a lot
PeeWee

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Wed, Jul 15 2009 at 8:56AM PDT

Since I moved my Data from one MacBook Pro to a new one using Migration Manager, I did the logic board / MAC re-pairing in the same time.

I don't want to spoil your success, but... So, you've used the Migration Assistent to copy your documents and some more (but not the whole system), after you installed Mac OS X (or, onto a system that had OS X pre-installed)? If so, then the old (and now current) backup is simply not a good representation of your current Mac. Thus: you might not be able to use it for a full restore!

I'd say this hint is only safe to reconnect a backup to its original hard disk.

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Wed, Jul 15 2009 at 9:28AM PDT

Though the 36 hours deep traversal may have fixed this after all...? In that case a full system restore may be possible, using this new backup or any newer backup (but not using backups that were created before the deep traversal, as I think those certainly do not match your current Mac).

10.5: Reconnect Time Machine backup after drive swap
Authored by: PeeWee on Wed, Jul 15 2009 at 3:07PM PDT

Thanks for your reply. My priority was to get the new machine ready to work as fast as possible. I first did a block copy clone of my entire HD onto that last generation MacBook Pro, but it wasn't really satisfied with my System. That's why I migrated it, yes the whole, while I cloned the Time Machine Partition to another Disk before starting to fumble on it.

I will (try to ;-) ) do a full restore onto another disk asap. Wanted to try that anyway. Will let you know.

10.5: Reconnect Time Machine backup after drive swap
Authored by: luhmann on Fri, Jul 17 2009 at 4:15AM PDT

I took a look at this, and thought: Surely this is not the Apple way? Sure enough, one can simply hold down the option key when selecting the time machine menu icon and one will see an option: "Browse Other Time Machine Disks" instead of "Enter Time Machine." Doing it this way you can restore from your previous backup without having to do ANY of the steps mentioned in this hint or the previous hint about new logic boards.

Of course, browsing an old backup is not the same as "reconnecting" in that Time Machine won't simply pick up where you left off. Best to buy a new drive, they are cheap enough, and save yourself the trouble. I know for a some people the above steps may not seem like trouble, but I believe most users will prefer to just hold down the option key to restore from a backup made on a previous computer/hard drive/logic board, and start over with a new backup after the switch.

As if ever hints here were for 'most people'
Authored by: hamarkus on Wed, Sep 30 2009 at 5:23AM PDT

A large proportion of hints here are not what 'most people' would do.

10.5: Reconnect Time Machine backup after drive swap
Authored by: david29 on Sun, Aug 2 2009 at 11:33PM PDT

I am amazed that no one has written some type of script or small app to handle this issue. I would gladly pay a few dollars for a solution.

I have tried the method on the page several times but cannot seem to get it to work. I am giving it another shot. Wish me luck!

10.5: Reconnect Time Machine backup after drive swap
Authored by: palahala on Mon, Aug 3 2009 at 12:22AM PDT

Hmmm, for a moment I thought you're also known as hartmut... ;-)

Please note that this only applies when using the exact same harddisk contents. You should not do this to associate an old backup with a new Mac. I guess that limits the market for fool-proof fully automated solutions. There's a script for the original hint though: 10.5: A script to fix Time Machine after hardware repairs. But some troubleshooting skills are required in case things fail, so I'd not really recommend such script if the manual steps are too difficult.

"Reconnect" Tip Broken under 10.6
Authored by: WaltFrench on Sun, Sep 27 2009 at 5:58PM PDT

This hint seems completely undone under 10.6.

First, fsaclctl seems to have gone missing. Some posts suggested there's a replacement fsacl but no man page that i could find.

Second, I'm concerned that the output of xattr showed 37 hex pairs, not the 32 hex digits and dashes. By the looks -- I've forgotten all my ASCII -- it is a hex representation of the actual hex UUID (43 41 ...) and its dashes (2D), terminated with 00. That's arguably the same as the UUID, but not quite close enough to give me the warm & fuzzies.

So, a show-stopper. Has anybody figured out how to proceed under Snow Leopard?

Maybe I have a solution
Authored by: hamarkus on Wed, Sep 30 2009 at 3:32AM PDT

From what I have gathered, an extended attribute in Snow Leopard can have as a 'default' representation hex OR ascii.
(1)Take a screenshot and run xattr -p com.apple.metadata:kMDItemScreenCaptureType Screenshot.png on it. You will get a hex representation. Run xattr -l on it and you get both hex and ascii.
(2) Create a new textfile in TextEdit and run xattr -p com.apple.TextEncoding File.txt on it. You will get an ascii representation of it. Run xattr -l on it, and you still get only ascii. Run xattr -px or xattr -lx on it and you get both hex and ascii.

This what I mean by having either a hex or a ascii representation as a default. Now how can be set things for both variants? The simple xattr -w nameofattribute value filename sets an attribute with ascii at the default view. But xattr -wx nameofattribute "valueinhex" filename sets an attribute with hex as the default view.

So far, pretty straightforward. But most extended attributes with hex as the default view run into multiple lines. I have so far only found somewhat of a kludge to set these: Create a multi-line environment variable in hex form and use this together with -wx. I'd be glad if somebody showed me a more elegant way of doing this.

Whether that makes this hint workable under Snow Leopard, I do not know.

Forget about that environment variable kludge
Authored by: hamarkus on Wed, Sep 30 2009 at 6:15AM PDT

These newlines are not actually new lines. Just enter the full hex string as an argument to -wx.

"Reconnect" Tip Broken under 10.6
Authored by: majorminor on Thu, Oct 8 2009 at 5:46PM PDT

My MBP was replaced with a iMac and opening Time Machine gave this;

http://img.skitch.com/20091009-1xn7hqrdcfmjxhxm8mmswgcw2s.jpg

which may work for Drive Replacement but guess it depends if it picks up the new MAC for the HD

---
honi soit qui mal e pense

[ Reply to This | # ]

10.5: Reconnect Time Machine backup after drive swap
Authored by: mwittle on Fri, Oct 9 2009 at 12:54PM PDT

I swapped my disk using the Disk Utility restore method, using the erase disk option, and that worked fine. Result was that the Time Machine sparsebundle file is now on a 1-TB drive instead of a 200-GB drive. Time Machine then ran fine nightly for a few weeks.

HOWEVER, now Time Machine posts an error message each night telling me that the disk is out of space, and is removing old backups, even though the disk still has 700-GB of space. How do I get Time Machine to recognize that the sparsebundle is now on a larger drive?

10.5: Reconnect Time Machine backup after drive swap
Authored by: badtux on Sat, Nov 7 2009 at 9:46PM PST

This doesn't appear to work under Snow Leopard. Problem #1: fsaclctl does not exist in Snow Leopard. Solution: Install /usr/sbin/fsaclctl out of the Leopard install disk that came with my Macbook Pro, from /Volumes/Mac OS X Install DVD/System/Installation/Packages/BSD.pkg , using whatever pkg extractor you desire (I used Pacifist) to make it work (extract only the single file, not the whole thing!). Problem #2, even after executing the commands in question with the up-to-date disk UID, Time Machine did a full backup of my just-restored data anyhow the next time it ran. So obviously something changed in Time Machine between 10.5 and 10.6 that broke this hint. Sigh!

Hint Options

Search

From our Sponsor...

User Functions

What's New:

Hints

Comments last 2 days

Links last 2 weeks

What's New in the Forums?

The Editor's Corner...

Hints by Topic

News from Macworld

The macosxhints Poll