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: Thu, 20 Jan 2011 07:52:11 -0700
Stan Sieler <mailto:email@hidden> wrote (Wednesday, January 19,
2011 11:51 AM -0800):
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 ...
Why is everyone always apologizing for philosophy? :)
The advantage of "near" is that an app can walk up to a file and say "what attributes do you have?"
Which is exactly what the CSBackupIsItemExcluded function does.
Give it a file and it will tell you what the file's backup
exclusion status is.
Knowing what the attributes are means that there is some chance that they can be carried over to
a copy/backup of the file.
But since this an OS API, applications don't have to worry about
it. Whether a copy retains the attribute is up to the OS and the
kind of attribute. A backup file would never have this
attribute, since a file with this attribute shouldn't be backed up.
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).
An OS API is better than any dot-underscore approach, because it
doesn't require an application to interpret the information.
That's an implementation detail of the OS, which the application
can blissfully ignore.
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.
The application doesn't have to know anything, except to call CSBackupIsItemExcluded.
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.
Again, this is an implementation detail that's the
responsibility of the OS. Whether a file retains the property
when renamed depends on the kind of backup exclusion set for
that file, so again it's not a decision for an application to make.
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) ...
I'm pretty sure that's exactly what's been implemented.
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 don't understand this statement.
I've explored the "Core" routines only a little ... they seem ill-suited for calling from C code.
I don't understand this statement either. Why would C functions
be "ill-suited" from being called from C code? I'm pretty sure
that the purpose of a C API is that it is well-suited to being
called from C. ;)
--
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