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: Stan Sieler <email@hidden>
- Date: Wed, 19 Jan 2011 10:51:33 -0800
Hi,
>
> I don't think it matters. The two API functions for excluding items from a backup (CSBackupIsItemExluded and CSBackupSetItemExcluded) are both "near" in that operate on the URL of the item. Whether the information for maintaining this property is "near" (i.e. an extended attribute) or "far" (an OS X database hidden on the volume) is an implementation detail--as long as it's reliable, of course.
>
Sorry to get into philosophy ... but ...
The advantage of "near" is that an app can walk up to a file and say "what attributes do you have?"
(It may not understand them, of course). (See note at end)
Knowing what the attributes are means that there is some chance that they can be carried over to
a copy/backup of the file.
With the dot-underscore approach, the metadata is "near" the file (not as near as it would be
if it was kept in the file system directory structure, but that also makes it fairly easily visible).
The disadvantage of "far" (using app-specific databases, e.g.: /var/timemachine/exclude_list (to make up an example))
is that new applications won't know about those databases.
Thus, if they do something like rename a file or copy/backup a file,
they won't know that there might be metadata about the file in these various and sundry databases.
The advantage of "far", is that for a given app the data is stored together.
That means that an app need look only in one place to get the information,
without doing a full directory search (like our fake TM app that uses /var/timemachine/exclude_list).
(And, the app can worry a bit less about a user corrupting the attribute data :)
Unix, in general, tends to use multiple "far" databases, probably the result of its development history
and initial developer's lack of experience. I'm happy to see Mac OS X exploring different possibilities.
The near/far question matters most when new apps are written by new people.
Of course, it's possible to implement a system that merges the best aspects of both
(e.g., a registry of "far" databases, with an API to access them) ... and I'm sure that if that was done,
and enforced, you'd be getting complaints from people complaining that you've departed from prior examples :)
>> I should have clarified that I expected a "they're excluded" answer ... and that I'm mostly fine with that.
>
> They're excluded. (feel better?)
Yes, thanks to answers from you and Michael and others!
> Time Machine has specific folders that it always ignores (cache, temporary, VM, ...) and you can programatically set any item to be excluded using the Backup Core API. Xcode, for example, uses CSBaeckupSetItemExcluded to exclude the build folder of its projects.
I've explored the "Core" routines only a little ... they seem ill-suited for calling from C code.
thanks,
Stan
_______________________________________________
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