In article <reply_in_group-CFC0C3.02005819022008@[EMAIL PROTECTED]
>,
Tim Smith <reply_in_group@[EMAIL PROTECTED]
> 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/Do***ents
> 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.
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
|
