HFS+ boondoggles; also, now backing up to UFS - WAS: Re: [Dirvish] dirvish: no incremental on Mac OS 10.4

Bernd Haug haug at berndhaug.net
Fri Oct 27 06:30:26 PDT 2006

Hash: SHA1

Robin Ericsson wrote:
> HFS+ works like that. If you open a file less that 16M (or something)
> it tries to defrag the file on the fly. However, I don't think a
> hidden FS feature like this would touch mtime though.

I'd totally agree, it certainly shouldn't.

But on the other hand, if what I read today about the link behaviour
certainly shouldn't happen either, but it seems to be true, judging
by the problems I experienced.

I've got nothing against emulation layers, but they have to be
totally transparent, everything else is just a bug, IMO.

To think that I was already sore about how they implemented
softlinks and aliases differently (softlinks, and empty regular
files with resource fork, respectively) instead of allowing creation
of link type files with resource fork...which is a much smaller problem.

Would allow cool stuff, like automounting volumes without extra
configuration by cd'ing into them and so on...

Back to the topic:

I have changed (or rather, copied everything away and re-mkfs'd it)
my backup volume to UFS BTW; the dirvish run is running right now.

Current situation is:
Filevault volume with HFS+ being backed up to UFS USB HDD using
local transport.

My rsync is:

[3|3]bhaug at pocketrocket:~$ rsync --version
rsync  version 2.5.5  protocol version 26
Copyright (C) 1996-2002 by Andrew Tridgell and others
Capabilities: 64-bit files, socketpairs, hard links, symlinks,
              no IPv6, 32-bit system inums, 64-bit internal inums
[3|4]bhaug at pocketrocket:~$

I will tell you tomorrow after the (hopefully) first incremental
whether it worked now. The target FS should support real hardlinks
in any case now.

Yours, Bernd

Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Dirvish mailing list