April 1st, 2006

belize

lutimes(2) and Linux

This homeboy is sad that lutimes(2) isn't implemented in Linux.

I didn't even know of lutimes earlier today, because I didn't even know of utime()/utimes(). I was like, "How can I get brackup to restore modtimes? I know tar and rsync do it." So I straced tar, found utime/utimes, was happy, implemented, then found it didn't work on symlinks (or rather, it tried to follow symlinks). Told Whitaker about lstat (vs stat), then he googled lutimes, found it, told me, and I find that Linux
doesn't implement it.

And that was after I straced tar on symlinks and found it didn't do anything, so I had little hope anyway.

But this breaks my brackup test suite which compares the output of "ls -lR" on backup dir and restored dir. So now I have to compare instead some new serialization of the before/after directories, ignoring symlink modtimes. Lame. I thought I was done.

Oh yeah, work on Brackup continues. It restores now. Coming soon to svn and CPAN near you.
belize

Losing an entry due to Mac/Safari?

My previous entry was temporarily lost, read this:

http://community.livejournal.com/lj_support/623509.html

After I found the entry in the pcap file and went to decode the form encoding to re-post it, I find this, the cause of the UTF-8 bug:

"do+any%10thing%2C+so+I+had+little+hope+anyway"

Notice the %10 in there? That's not a valid UTF-8 byte, at least in the strict interpretation, which expat follows. Why the hell did Safari send it? Did I type something weird? Still.
belize

Brackup update

Go snag the latest copy of Brackup:

$ svn co http://code.sixapart.com/svn/brackup/trunk brackup

Notably, it now has:

-- restore support
-- the ability to preserve modes/times
-- a really nice test suite

I'll do a tag and release once the docs are updated, probably tomorrow. The Filesystem driver is fully up-to-date, but the Amazon driver is missing the restore methods.

In case I forget, the new decisions made are:

-- backups must be automatable, not requiring user input. this was already a design rule, but now it's formalized. (for instance, already had the idea of just the public key to encrypt, etc.)

-- restores may prompt for user input ("What's your Amazon S3 password?" and "Enter your GPG passphrase."), because they won't be automated or common. and I don't want a restore to require a fully setup ~/.brackup.conf. You probably lost it anyway. So a *.brackup metafile (the one you get after a backup) should contain all the metadata necessary to restore (say, Amazon S3 username), but not secret stuff.

If you try to restore from a driver that doesn't implement the "load_chunk" method you'll just get an error like, "This driver doesn't support restoring." until they're updated. (I'm thinking of the GMail target on CPAN.....)

Shout-outs to the brave people like kvance who are using this already, even before it had restore support. BTW, if you're using Amazon, add the "exist_cache = [filename]" in your [TARGET:amazon] config, so it doesn't have to do HEAD requests on every already-uploaded chunk to verify it already exists. Makes backups tons faster. Note to self: issue loud warning about non-existant existence-caches.