For what it's worth, I'm using netatalk 2.0.3 on FreeBSD 6.2. backupdb bundle.Īgain, this is preliminary, and I'm still testing, but it really appears that this has worked, at least partially here. When it starts "preparing" it should create a new sparseBundle disk image alongside the. This is just to make Time-Machine backup again in 120s. Enable a couple more files or so to be backed-up.That's OK though, it should be reflected in name and available space in the Time Machine pane. If you click "Change Disk" you will not see the netatalk share.Remove the external disk (you may want to rename it before), rename the netatalk share, remount it, and re-enable Time Machine.Once Time Machine has done the initial backup to the external disk, disable Time Machine (I don't know how necessary that is yet), and rsync them, ala the link above (sudo rsync -xrlptgoEv -progress -delete /Volumes/Backup/ /Volumes/Backup1/).Setup your netatalk share appropriately, named differently (for now) from the above disk.Name the disk appropriately as well, as our end goal is to rename the netatalk share to this name. It's probably best to exclude everything but a couple of tiny files or so. Setup an external disk like you normally would.So, this is highly preliminary, but I seem to have been successful in performing something similar to the above linked procedure, except without the second mac. If someone could confirm, that would be interesting in itself. As I understand it, hard linked directories will appear as symlinks (?) on non-leopard Macs. I'm curious how hard linked directories were hacked on to this system. It did come with a performance hit of doubling up the disk accesses for multi-linked files or somesuch.Īgain, this is just something I read on some crazy website, but it seemed fairly reasonable to me. This was all done at the bare HFS level and invisible from outside the file system. The implementation was something to the effect of moving any files with more than one link to a special hidden directory and then leaving special pointer files in their place. This gist, as I remember it, was that HFS and HFS+ do not "natively" support hard linked files, so a workaround is done in the file system driver which can provide hard link semantics to all the software above (basically anything that uses file system APIs instead of reading bare blocks off the device). I'm pretty sure it was on Rixstep, a site which is mostly the insane ramblings of a NeXTStep greybeard. I can't find the original article I read on this topic. So what was the kludgy bit about hard links in HFS+?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |