A more plausible version of this scenario:
cp -pr current working
... make deep changes in working, and when satisfied ...
mv current old
mv working current
Now current looks unchanged, but it may have changes deep inside.
(The use of -p is so that only edited files will get new modification times.)
On Jan 14, 2011, at 7:51 AM, James Bucanek wrote:
> Dominic Giampaolo <mailto:email@hidden> wrote (Thursday, January 13, 2011 9:12 PM -0800):
>>>> ... I can demonstrate one (perhaps pathological) case where Time Machine fails to back up a file.
>>> Alan originally contacted me about this issue, and I can now confirm that
>>> the scenario he described is a pretty serious problem.
>> We are aware that it's a real problem but the question
>> is how common is this scenario? To us it seems quite
>> unusual to rename a directory, do stuff inside it,
>> rename it back *and* do nothing else that would bump
>> the mtime on the directory.
> I'm beginning to think it's more common than I originally thought. For example, I have one customer who has documented a reproducible FSEvent failure. The missed change event occurs deep inside a virtual machine package directory that contains lots of working and temporary directories.
> I agree that it's unlikely that one would rename a directory, change a file inside it, and rename it back without otherwise changing its modification time or anything else. (I'm going to try to document some real-world instance of this today or tomorrow.)
> I think the real problem occurs when the significant change is in subdirectory or two removed from the directory that's getting renamed. So even if the renamed directory is touched, there's still no way to determine if one of the subsidiary items has changed without an exhaustive search of its contents.
> From a philosophical standpoint, "unusual" is immaterial. FSEvents needs to reliably report all change events. Advertising that my backup solution will incrementally capture "most of your changes" isn't a big selling feature. ;)
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden