puzzling bug in iDisk file syncing

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 support 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 reported this bug to Apple, along with the details on
reproducing it. I've also reported 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

In article <reply_in_group-CFC0C3.02005819022008 DeleteThis @news.supernews.com>,
Tim Smith <reply_in_group DeleteThis @mouse-potato.com> wrote:

> 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 support 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.

Even if it is to the filesystem, it need not be to code observing the
file system. In particular, I guess that FSEvents marks the directory as
needing changes.

Warning: that is just a guess. I did not even verify your claims, let
alone test that guess.

Reinder