Re: using FSevents for backup - is it reliable enough?
Re: using FSevents for backup - is it reliable enough?
- Subject: Re: using FSevents for backup - is it reliable enough?
- From: James Bucanek <email@hidden>
- Date: Fri, 14 Jan 2011 08:51:23 -0700
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. ;)
I'm actually rather surprised this is happening. When I talked to an Apple
Engineer at the time when Time Machine was introduced (WWDC
2006?), I though they said that the FSEvents were tracked
using the nodeID of
the modified directory, not its path. So the path reported in the historic
event stream should be the path of the modified folder as it exists now (i.e.
Users/james/Desktop/Test/a/b/c/d/e/), not its path when it was modified (i.e.
not Users/james/Desktop/Test/x/b/c/d/e/).
I'm not sure how told you that but it's not true.
I don't either. 2006 was a long, long, time ago. It's like BIP
(Before iPhone).
It
has been proposed as a possible solution but you can't
just do that since when a file is deleted you want to
know about that but there's not inode number any more.
I'm sure there might be other reasons, but that one shouldn't be
a problem. FSEvents report change events for the enclosing
folder, not the item that was deleted, so the nodeID of the
deleted item is moot. My application will receive the change
event for its enclosing directory, and it's my job to detect
that one of its enclosed items is now gone.
I can, however, see a more general problem with storing the
nodeID for deleted items in the historic log. I don't know how
nodeIDs are recycled, but I can see where detecting whether a
nodeID has been subsequently reassigned could prove to be problematic.
--
James Bucanek
_______________________________________________
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