I expected timedog to accept --help or -h to show help.  It did not.

And not just because I think it's a good idea, but because Google Code is 
shutting down.

http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

There is a tool that automates most of the migration.

This is a request for a new feature. 

Most TM problems arise from pushing huge backup sets to the disk. I think most 
users use tools like timedog to determine what large files are being backed up. 
While this is useful after the backup has taken place, it would be also useful 
to determine which files will be backed up during the next backup (just as TM 
does) and providing a manifest of these along with the file sizes. This way a 
user could exclude large file sets from the backup prior the pushing the backup 
to the disk. 

When not running the current version of timedog as root (so, even when running 
as an admin 
user), it silently ignores (or simply doesn't know about) files it cannot 
access. This also yields a 
lower total size of changed files. I don't think this is a common problem 
(though maybe plain 
users, without admin rights, need sudo all the time), so maybe this could 
simply be 
documented.

For example, running as an admin user:

~/Downloads/timedog -d 1
==> Comparing TM backup 2009-07-09-213048 to 2009-07-01-140540
    Depth: 1 directories  
    3.2KB->    3.2KB        /.Backup.log
       0B->       0B        /.com.apple.TMCheckpoint
     788B->     788B        /.exclusions.plist
   35.7MB->   60.3MB [1416] /Macintosh HD/
==> Total Backup: 1421 changed files/directories, 60.34MB


sudo ~/Downloads/timedog -d 1
Password:
==> Comparing TM backup 2009-07-09-213048 to 2009-07-01-140540
    Depth: 1 directories  
    3.2KB->    3.2KB        /.Backup.log
       0B->       0B        /.com.apple.TMCheckpoint
     788B->     788B        /.exclusions.plist
   14.3GB->   14.4GB [1423] /Macintosh HD/
==> Total Backup: 1428 changed files/directories, 14.36GB

My backup disk is attached to a remote Mac mini, so it's a sparsebundle.

The same issue occurs in TimeTracker. I found it because the logs stated many 
GBs were used, 
and disk space did indeed decrease by many GBs. However, timedog and 
TimeTracker only 
reported a much lower value. Using "find . -mtime -10" in the latest backup I 
got a warning:

    find: ./Macintosh HD/usr/local/mysql-5.0.51a-osx10.5-x86/data: Permission denied

And that folder indeed showed a 11 GB log file, and a 3.5 GB database. This 
folder is owned by 
user _mysql, group wheel.

JD points out that auto-discovering and mounting the Time Machine volume
would be a nice feature. It seems that tms has this, so should be simple
enough to see how they do it.

Do not ignore root directory for Local Snapshots even if inodes are identical 

From michaschnecke:

While I am not an expert in Python, I have following directory message,
which confuses me:

whitebook:Desktop micha$ sudo ./timecopy.py /Volumes/hfs /Volumes/whitebook
Traceback (most recent call last):
  File "./timecopy.py", line 499, in <module>
    main()
  File "./timecopy.py", line 493, in main
    copybackupdb(src, dst, verbose, dryrun, extattr)
  File "./timecopy.py", line 326, in copybackupdb
    entries = os.listdir(src)
OSError: [Errno 20] Not a directory:
'/Volumes/hfs/Backups.backupdb/.com.apple.timemachine.supported'

My TM sparse bundle disk image has an "invalid sibling link" error, and one
strategy I'm employing to correct this "unfixable" error is to use the
trial version of Super Duper! to copy the TM files over to a new disk
image. It seems to be working fine, but it's extremely slow: 100GB in about
36 hours. While Super Duper! is handling the hard links properly, it's
spending a lot of time resolving them across the entire file system. It
would go a lot faster if it were aware of the TM file structure, as timedog
is. In email communication with the SD people, it became clear that they
don't see this as a problem. I, however, do.

I propose a new script, call it timecopy, that does one thing well: copies
a TM volume to another volume. It will traverse the directories in date
order and discover the hard links, reproducing the same structure in the
new volume, and copying over the files as needed. For bonus points, it
should be able to resume from where a previous copy left off. That is,
discover that the target volume already has some number of backups and
start from where it left off, copying any new backups from the source to
the target.

For people that use Time Capsule, they may be unaware of how to mount their
backup image, and until then, timedog won't work for them. Basically it's
just a matter of opening Disk Utility and mounting the sparse bundle disk
image.

What steps will reproduce the problem?
1. run timedob -d 5 -l

What is the expected output? What do you see instead?
I am supposed to get some results but all I get is "nvalid top directory at 
/System/Library/Perl/5.8.8/File/Find.pm line 592."

What version of the product are you using? On what operating system?
The latest as of now. Just downloaded the file.

Please provide any additional information below.
OS: X Leopard
Backup Device: Time Capsule

Sean has submitted a patch that JD committed in rev 9. Make a new build and
put on the downloads page.