Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Back up your Contacts database automatically ' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Back up your Contacts database automatically
Authored by: leichter on Mar 10, '13 05:58:34AM

Be very careful using this hint. If you have multiple systems sharing the same Dropbox file, simultaneous updates might leave you with an unusable Contacts database.

More detail: It's been pointed out repeatedly that sharing a file through Dropbox can lead to a "broken" file if two machines modify it at the same time. (It's not really "at the same time" - if a machine modifies the file while it doesn't have a network connection, "at the same time" covers the entire period from the last sync to the next.) While it's less likely, it's even possible for Dropbox to save a partially written, hence unusable, copy of the file.

This problem can only occur when a file is modified in place: That is, *the original file has its contents modified*. This turns out to be surprisingly rare in OS X programs. Most programs (a) read the old file; (b) write a new, temporary file with the modified contents; (c) rename the temporary file to the old file's name while simultaneously deleting the old file. From the user's point of view, there's a file with the same name as the old but with new contents; but the from the system's - and Dropbox's - point of view, there's a whole new file. At no point will Dropbox try to save a copy of a file *as it's being rewritten*: It sees either the complete old file or the complete new file.

I know of no way to check what strategy a given program is using from Finder, but it's easy from Terminal: Use the command "ls -i" on the file. For example:

$ ls -i /Users/leichter/Library/Application\ Support/AddressBook/AddressBook-v22.abcddb
354238 /Users/leichter/Library/Application Support/AddressBook/AddressBook-v22.abcddb

The number "354238" before the name of the file is an internal identifier for the file ("inode number" in traditional Unix; Mac directories don't actually have inode's, but they have identifiers that play a similar role). Copying the file gives you an identical file - but it will show a different number:

$ cp /Users/leichter/Library/Application\ Support/AddressBook/AddressBook-v22.abcddb /tmp/foo
$ ls -i /tmp/foo
19793033 /tmp/foo

If you compare inode numbers before and after you make a modification to the Contacts database, you'll see that the inode number remains the same. AddressBook has changed the file "in place".

For an example of a program that uses the "copy and rename" strategy, you can try KeyChain Access: If you modify a keychain - even trivially, like changing the name of key, the inode number on the keychain file (in /Users/username/Library/Keychains) will change.

So saving your Contacts list in Dropbox is dangerous, but saving your keychains there is fine: The worst that can happen, in the case of simultaneous changes, is that you end up with conflicted copies which you'll have to resolve.

---
-- Jerry



[ Reply to This | # ]
Back up your Contacts database automatically
Authored by: beepotato on Mar 11, '13 03:19:06PM

Beware that with Mac OS, what can appear as modifying a file in place may actually not be.

Indeed, the HFS filesystem provides a very convenient function to swap the data of two files atomically. It is usually used for safe saving, by first writing the new version of a document to a temporary file, then swapping the data of that temporary file with that of the original file, before deleting the temporary file.

With this process, no software will risk accessing a half-modified, inconsistent file, just as with the file-swapping technique that you described. But the advantage over "manual" file swapping is that the data ends up in the same file as before, with the same file ID (hence not breaking references to the file made through its ID).
When checking with "ls -i", it would look like no temporary file was used, when one actually was.

An equivalent to that function is absent from most (all?) of the other filesystems, as far as I know.
If you want to learn more about it: "man exchangedata".



[ Reply to This | # ]
Back up your Contacts database automatically
Authored by: leichter on Mar 11, '13 07:57:35PM

man exchangedata on my Lion system reports "No manual entry for exchange data". Could this call (or at least *documentation* of this call) be new to Mountain Lion?

Note that an operation like this requires OS/file system support. When was it added to AFS? Do AFS servers support it?

There's a paper somewhere out there - I can't find it again now - which looked into how files and file systems are used on contemporary systems, updating a classic analysis of Unix file system usage that goes back 10-15 or so. They chose to look at OS X, and found many surprises - including the heavy use of "rename", which they tracked back to the "copy and rename" behavior of many common Mac applications. It looks as if Apple has added a call to provide support for this style of update, though how widely it's used at this point, I don't know.

---
-- Jerry



[ Reply to This | # ]
Back up your Contacts database automatically
Authored by: beepotato on Mar 12, '13 05:52:55AM

That functionality predates Mac OS X. I don't know if it was introduced with HFS+ (Mac OS 8) or if it was already present in HFS (in 1987).

So, it has been present in Mac OS X since version 10.0.

If you don't have the man page on your machine, it's probably the you have not installed the developer tools (or have not installed all the documentation). Anyway, the man page can be found online:

https://developer.apple.com/library/mac/#DOCUMENTATION/Darwin/Reference/ManPages/man2/exchangedata.2.html


They chose to look at OS X, and found many surprises - including the heavy use of "rename", which they tracked back to the "copy and rename" behavior of many common Mac applications. It looks as if Apple has added a call to provide support for this style of update, though how widely it's used at this point, I don't know.

It is widely used, mainly because the NSDocument class uses it by default when saving. So all the NSDocument-based applications get it for free.

However, NSDocument used to do it "the old way" (through "rename") in early versions of Mac OS X (probably inheriting it from NeXTStep). I remember reading release notes for whichever version of Cocoa describing the move to rely on the HFS data swapping functionality (which, until then, was used mostly by Carbon-based applications).

Depending on when that study of filesystem usage was done, the above may explain the heavy use of "rename" in Mac OS X. It is probably used a lot less now.



[ Reply to This | # ]