Right, most package formats these days are handled real-time by the Finder and a central database. This can be tested by creating an RTF called
TXT.rtf and then dropping it into a folder named
test.rtfd. Poof, you get a valid RTFD file.
But it seems that sparse bundles still rely on the resource fork from what I can tell (they are in fact created with it set). Doing the above manual process and copying the internal components of an existing sparse bundle into a directory
test.sparsebundle will simply result in a folder. You have to set the bundle bit in the resource fork before it will work—then it does so flawlessly. I would imagine the above description is precisely what happens when DropBox assembles a new sparse bundle on the second computer.
They have announced that they will be addressing resource forks in the future, so hopefully this will not be a permanent issue. I think, for the time being, your advice in the manual is best. Not everyone knows how to mess with resource forks, and there is a slight risk that DB is doing something potentially damaging. I don’t know how integrated the band files are of a sparse bundle package. I guess my byte test would suggest they are merely sequentially loaded 8mb chunks; if they were striped at all, damaging one would cause major errors.
But isn’t Dropbox supposed to be smart about only uploading the changed parts of the file?
Unfortunately, no. It is smart about what “changed” means. It doesn’t simply check modification times, rather it uses a database of hashes to determine file equality. But when it comes to byte level granularity that doesn’t seem to exist. I just tested this by changing one text file in my EF library, closing it, and then unmounting the image. It is now transferring the entire image file.
I think the other drawback to images (as opposed to bundles) is that OS X doesn’t update the disk as often (or perhaps at all?). I had it open for a while, and it wouldn’t upload to DropBox until unmounted. Perhaps Apple holds the working data for such a disk in a temporary location instead of updating the source image file as it is edited.
With sparse bundles, that is different. Each band file gets updated synchronously with user changes, which registers as a file level change with DropBox. So the bundle file gets continuously updated as you work in it.
Another reason to use EagleFiler’s end-to-end file verification.
Ha. Without doubt!