This isn't really a programmer issue, other than knowing about this bug
might let you design your apps to work around it, but I'm puzzled as to
HOW this bug works, and this seems the most likely group to figure it
out.
Consider this shell script:
#!/bin/bash
VOL=/Volumes/iDisk/Documents
NAME="foo"
mkdir $VOL/tmp
date > $VOL/tmp/data.txt
mv $VOL/$NAME $VOL/tmp.old
mv $VOL/tmp $VOL/$NAME
#touch $VOL/$NAME/data.txt
rm -rf $VOL/tmp.old
cat $VOL/$NAME/data.txt
Run it with your local copy of your iDisk mounted on /Volumes/iDisk, and
it makes a directory named foo, containing a file, data.txt, that just
contains a timestamp.
(Note that this is using the classic procedure for overwriting a file on
a filesystem that doesn't sup****t transactions--a procedure that is
probably pretty common).
Sync the iDisk, and foo and data.txt go up, as expected. Run the script
again, and sync again, and it catches that, as you'd expect.
Now edit the shell script, and change NAME to "foo.app" or "foo.oo3" (or
probably any other extension that is treated as a package by Finder
rather than as a directory).
After the first run, which creates foo.app, it syncs fine. Run it
again, and it does NOT pick up that foo.app needs to sync. Run it again
and sync. Nadda. Repeat until bored.
However, if you uncomment the touch line, then syncing works. That's
what puzzles me. Checking the times of foo.app and data.txt with stat,
most of the time they are all the same. The filesystem only seems to
keep access/create/modify times to the second, and most of the time, the
touch will occur in the same second the file was created, and so not
change any timestamp. (I know that the timespec struct used has seconds
and nanoseconds in it, but the naneseconds always appear to be zero).
I don't see any other metadata or other information about the file or
directory changed by the touch, either. As far as I can tell, a touch
of a file that occurs in the same second the file is created is a no op.
So how come the touch makes a difference? What is it changing that I'm
missing (and the iDisk Sync looks at).
PS: I've re****ted this bug to Apple, along with the details on
reproducing it. I've also re****ted it to the Omni Group, since
OmniOutliner documents are directories with an XML file in them, and run
smack dab into this bug.
--
--Tim Smith
|
