[dnanian]

ZeroScan basically relies upon the 'fsevents' daemon, which is a kernel-level feature that 'broadcasts' all file changes at a very low level. It was exposed differently in Leopard so that you can find out what folders have been modified for a given time.

There are a lot of disadvantages to using the 'older' style, which ZeroScan was originally based on, most of which are highly technical and beyond the scope of what I think is appropriate.

In Leopard, the new FSEvents database has some advantages -- since it's fully supported and doesn't require kernel-level event trapping. But it's also brand new technology, has some fragility that requires full scanning in many situations, and isn't yet terribly mature.

Since SuperDuper! can scan and backup quite quickly -- for example, my own typical 2+million file backup takes about 20 minutes, including the time to scan and copy. Since it's scheduled for the middle of the night, I don't really care about the minutes that might be saved by doing the scan a different way, especially given the fact that it might need to be done that way anyway... considering that the underlying facility to provide the information is still pretty young, and really only 'properly' available in Leopard (and we support Tiger, too).

So -- while we're looking at FSEvents for future versions of SuperDuper! -- the time saved didn't seem worth the risks... especially given the fact that SD! (unlike Time Machine, which also uses FSEvents) isn't designed to run constantly, and is typically run when you can certainly afford the extra few minutes needed to do a full, complete, thorough -- and correct -- scan.