Home Forums Mac Software Mac Operating Systems Get Info / Languages

CleanApp is similar to Youpi except that it costs money,$15, oh well. . .

I just discovered MacPilot will also remove localization files.

Things appear to have improved somewhat with Snow Leopard.....

=====
159.24 megs total for 1353 items.
=====

was the result I got and it was from only 5 apps.....iWeb, iPhoto 8.1, Skype, HP Setup Assistant, and the Bluetooth Firmware Update (which I think is a legacy from past OS's....).

Looks great... until we point it into a Time Machine backup subfolder. i have indexing enabled on that volume... and using mdls shows plenty of metadata on various items there. Just that mdfind produces what i can only call "imaginary" output. I give up. [i can still play with my fbi script on regular disks though, but that wasn't the end i was meaning to reach.]

I have tinkered briefly with 2 GUI tools, so that looks like the way to go. File Buddy would have been promising (especially since it can total the size of found files). Unfortunately it tries to build and sort its list before displaying any items (like the dual xargs). EasyFind works nicely, as it builds its list on the fly (à la while-read-do). Unfortunately, i don't see any way for it to report the total size. When i selected 3000+ items in a limited /Applications folder search, it tried to open 3000+ individual Get Info windows... so i had to force quit.

HOWEVER, I'm starting to understand that we cannot select the "Backups.backupdb" folder itself as the source to search. It's too big, and it actually represents many versions of our HD. But something like Backups.backupdb/computername/2009-11-11-001247/MacHD (or use the "Latest" symlink) is the way to go for calculating ... no wait, that would miss some designable.nib files in outdated backups. Perhaps "walk" across all backups and capture the found items along with their *inode* numbers. Then sort that list and remove duplicate inodes.

Hmm, it's quite a puzzle actually. [a special tool would be needed... i.e., neither EasyFind nor anything not specifically designed to walk through all those multi-linked directories and then remove duplicate inodes will ever produce truly accurate results.]

Nah. Finder may show you a bundle as if it were a file, but to Time Machine it's just another folder. Time Machine will treat it just like any other folder with some items deleted: it has to create a new directory with a shorter list of contained items, but none of the unchanged files would be copied again.

That's why Time Machine gets along so well with .sparsebundle disk images. It sees each 8MB band as a separate file, and only copies those bands that changed.

True. But it still did some sort of backing up action to "record" everything that changed (even if it was done with a clever use of links). My intended point wasn't so much that free space on the backup disk would decrease (or increase for most other backup types), but simply that the story doesn't end the instant a ton of languages are removed... and that there will be a ripple effect of some sort [since backup apps will perceive a mass change, and then do whatever it is they're configured to do (depending on the type of backup), in response to that change.] Just wanted to remind readers (or otherwise make them aware) that their next backup will be considerably busier than usual.

i like using exclusions in rsync (and GUI utils that provide them), to see to it that certain items don't ever get backed up in the first place.


Don't get me wrong... i am in absolute awe of Time Machine. I think that whole snapshot business is brilliant (was that Rubel's concept in the beginning?... or, where/when did it originate then?). It does get bizarre at times though, if/when we try to approach "Backups.backupd" as if it were an ordinary folder... because it's a lot 'hairier' than that.



There are situatons however where TM is not quite as efficient as some users might expect. Say we have a huge folder with a zillion items... and we decide to rename (or move) that folder. Instead of recording just that renaming (or moving) "event" somehow... this time, all that recopying (i.e., total duplication of data) does occur.  Does it not?


--

BTW, in case anyone thought of it... i did try substituting kMDItemDisplayName above (including all the stuff on page 1) with kMDItemFSName the other day, but it makes no difference [where anything inside Backups.backupd is concerned.]

It is. However, I saw a comment on, I believe, MacOSXHints to the effect that Snow Leopard's Finder will copy "Backups.backupd" correctly in response to a simple drag and drop. I couldn't find a reference to that anywhere in the release notes, but as it turned out I had a virgin disk drive that I had just gotten with the specific intention of backing up my Time Machine backup. (I had just had my second Time Machine drive die on me, and while I didn't lose any data either time it irks me to lose all that history.)

So I tried it. Finder warned me I might have to authenticate afterwards, but then went ahead and did the copy. I checked the copy every which way I could, and found no problems with it. du says it was exactly the same number of sectors as the original. All the permissions were correct, including all the ACLs. The extended attributes (including com.apple.metadata:_kTimeMachine{Old,New}estBackup) were copied faithfully.

And when I told Time Machine that I now wanted to back up to the copy instead of the original, it obligingly accepted the copy as a legitimate backup, copying over only the files that had changed in the meantime.

The final test was when I told SuperDuper to copy it again, and SuperDuper (which is certified to clone TM backups correctly) reported the same differences as TM had.

It does. And if you then move the folder back where it was, TM will copy the whole thing again, even though that folder is already present at that location in an earlier backup. TM only compares NOW with "Latest good backup".

I've also noticed that TM does not preserve hard links. If you have two files hard-linked together, TM copies it as two separate files. (You can check this by using (appropriately enough)
ls -li {,/Volumes/*/Backups.backupdb/*/Latest/*}/bin/{ln,link}
to verify that /bin/ln and /bin/link are hard-linked to each other, but their TM backups are not.