Please pardon the length of this post - but it may help the discussion. In case anyone is wondering as to it's usefulness I am in the process of using/evaluating this tool.
On MacOSXHints.com I found a thread that pointed me to macfixit.com which mentions DiskTop from http://www.prgrsoft.com/pages/products.html The suggested steps: This requires a separate partition for both your OSX, 9.1 and backup volume. 1. Boot from your 9.1 partition 2. drag the closed volume icon of your OSX volume directly on top of the backup volume. Lets say your OSX volume is called "Dart". This will create a folder on your backup volume that is called "Dart". The necessary invisible files will be inside this folder. 3. open the folder, and from the finder do a "select all" and drag the contents to the root level of the backup volume. (the invisible files stay behind) 4. Using disktop, open the "dart" folder. select all, move to the root level. Again, this requires that you are using a HFS+ filesystem and not UFS AND it requires two or more HD (I have twin 36GB in mine, so I might get it to work...) Anyhow, please refer to the Apple 'recommendations' about moving away from forks, etc, in the below README file (included here for completeness.) Regards; -Sx- About hfspax Why hfspax? hfspax is a modified (alright, hacked!) version of the standard Mac OS X and UNIX tool, pax. It addresses one of the few significant omissions from Mac OS X – the ability to perform proper backups, and to restore from them. Forks and resources Mac OS X is a remarkable hybrid operating system which manages to bring the power and strength of UNIX and the accessibility of Mac OS to a very wide range of users. In doing so, it has support for many legacy features from Mac OS 8 and 9, including the Mac OS Extended disk format (HFS+) and its unusual 'forked' file structure. Versions of Mac OS prior to Mac OS X have allowed every file to have two separate 'forks': the standard, or data, fork is normally used for linear data storage, whilst the other fork holds 'resources', such as window layouts, dialog text in different languages, and preferences. Mac OS is not the only operating system to support forks in files, but the great majority of computers in use today (Windows family, UNIX) cannot support forks in this way. Apple is encouraging Mac OS X developers away from dependence on resource forks, either in their applications or their documents. Whilst cross-platform applications such as Microsoft Office already make little use of resource forks, many Mac applications that have been ported to Mac OS X still rely on them. So, if you are running Mac OS X with Extended (HFS+) format hard disks and using Mac applications, the chances are that you are dependent on resource forks and the information stored in them. backup, tar, cpio, pax It may come as a bit of a bombshell to discover that, whilst Mac OS X does support resource forks, the backup tools provided with it do not. If you have started to explore the huge range of wonderful tools available from Terminal, the command shell, you may have discovered standard backup tools like backup, tar, cpio, and pax – all provided free within Mac OS X. But if you try to use them, you will discover that they all trash every single resource fork. If you want to test this out, make sure that you do so with a folder full of unimportant files. You can then modify the commands provided for hfspax to call the standard pax utility, or use those given in the references at the end. If your test folder contains 'plain' Mac OS X files (as you will find in /bin and /sbin folders normally hidden from the Finder's view), the tools provided work fine. But with Carbonised applications, their supporting files and documents, and many other files, you will get back rather less than you need. This would wreak havoc on a full Applications folder, and you would end up having to restore many of the applications from disk (or download). Retrospect, SwitchBack, SynkX At the same time, backup applications written for Mac OS 8/9 (and Finder copies) are insufficient, as they cannot cope properly with the new features of Mac OS X – new types of link (or alias), hidden system files and folders, and so on. In time, Dantz Retrospect should offer a range of commercial backup tools that meet Mac OS X's demands. Shareware tools such as SwitchBack and SynkX are very good at making duplicate copies of folders. However, they are not designed to work with archive files of the type normally created when backing up large, complicated operating systems such as Mac OS X. dd, ditto There are two shell commands that can provide reliable backups in certain circumstances. dd (try man dd in Terminal) will duplicate a volume by copying its blocks to another. This is close to the metal, useful in certain circumstances, but far from ideal for regular backups. ditto (man ditto) has a hidden option to duplicate folders with any resource forks. To discover this feature of its syntax, you will need to elicit its usage response, for instance by typing ditto and pressing return (in Terminal). You will then see the -rsrcFork option which performs folder duplication preserving resource forks. Again, this could be useful at times, but is far from being the ideal backup solution. Apple Software Restore Apple has provided a reliable and complete way of backing up Mac OS X volumes, using the Disk Copy utility and Apple Software Restore. In brief, you have to run Disk Copy from a volume different to the one you want to back up. Create a disk image of the whole volume – this can take a long time, so you may want to go out to lunch whilst Disk Copy is busy – and you can then restore from that when you wish. Although there is a compression option, such disk images are single files around 60%–75% (100% if uncompressed) of the size of the occupied portions of the volume. This could be entertaining if you have 6 or 8 Gbyte of files to be backed up, with only 4 Gbyte of free disk space and a CD-R drive to play with. Apple primarily advocates this scheme for developers and others who might trash a volume during debugging, and need to recover the volume. It is documented at Apple's developer site (developer.apple.com), but should not be your first choice for backup and recovery. It is also worth noting that, currently at least, Disk Copy for Mac OS 9 cannot work with single images larger than 2 Gbyte in size. A solution hfspax was developed to try to plug this serious gap. If you are still not convinced that there is a problem, choose one of the above methods, and then make some typical backups – a full backup of the Users folder, Applications perhaps, and then try a crucial system-level folder like /private, and the top-level Mach kernel files themselves. Time how long it takes, and then try restoring from them. If you have a quick, efficient and reliable method that preserves resource forks, Finder info, and Mac OS X links and hidden files, then please let me know and I will move on to developing something else. What does hfspax do? hfspax is a direct substitute for the tool pax, which is documented in its man (manual) pages, and in all good books about UNIX. pax was chosen for several reasons: first, it supports both cpio and tar, and several variants of each; second, its source code was particularly suitable for modifcations of the type required; third, it is full-featured. Some UNIX gurus dislike pax, because they see it as being less flexible than equivalent individual GNU tools, GNUtar in particular. Maybe in time these will also be converted to work with HFS+ peculiarities such as resource forks. Modes Just like pax, hfspax works in three modes – it can read individual files and archive them into a single .pax file; it can read an archive file and write out the individual files contained therein; and it can list the files archived in its .pax archives. Resource forks In addition to working with the standard data forks that pax will handle perfectly well, hfspax stores two additional types of pseudo-file. Resource forks are archived using a special suffix, so that the resource fork belonging to the data fork of the file myfile.rtf is stored as a pseudo-file named myfile.rtf/..namedfork/rsrc This apparently verbose convention has been adopted because that is exactly what Mac OS X does. (Bernhard Baehr and others have kindly pointed out that there is also OS X support for the resource fork through the naming convention myfile.rtf/rsrc. However, this appears to be undocumented and may not be supported in the future.). If you are familiar with the Terminal command shell, cd to a folder containing files that have resource forks, and type ls -la to see a full directory listing. Then type ls -la */..namedfork/rsrc, and you will see a listing of all the resource forks. Several users have pointed out that this does not always appear to work, whilst the command ls -la */rsrc may actually be more consistently reliable. If you can work out what is going on here, please let me know. Finder info The other type of pseudo-file adopts a similar convention to store the special Finder information for each file. That includes the four-character codes to identify each file's creator application, and file type. Once again, this is an area inherited from Mac OS 8/9 that should ultimately become unimportant in Mac OS X. However, the Finder uses this file type and creator information to decide which application should be used to open a document when you double-click on it. If the Finder information is not backed up, it will cause you problems if you have to restore from your archive. hfspax stores this information as a pseudo-file, using the suffix /..namedfork/finf so that myfile.rtf has Finder information stored in the pseudo-file myfile.rtf/..namedfork/rsrc. Please note that this convention is peculiar to hfspax at present, and (unlike those for resource forks) will not work in any shell. However, I would encourage others to use the same convention when appropriate. Design goals This design was chosen for a number of reasons, centred on the desire to retain as much compatibility as possible with pax and related UNIX tools. It would have been very easy to create another new archive format which bundled data and resource forks, and Finder information, into a single entity. But, in the event that you could not use hfspax, your archive would be inaccessible. Another option would have been to pre-process files into a standard 'flattened' form without forks. This could have been done using MacBinary, for instance, which is widely supported. However, this appeared to be inefficient, and little less accessible than a new archive format. In essence, then, when you write a new archive file, hfspax identifies a file and stores its data fork in the archive under the file's regular name. It then looks for any resource fork, and stores that as a pseudo-file under its extended name. It then stores the file's Finder information as another pseudo-file with an extended name. When you list the contents of an archive, the file and its two associated pseudo-files will also be listed. When you read an archive file and write out its constituent files, the data fork will be written out first, then any resource fork is restored, and finally the file's Finder information is restored. Note that hfspax behaves like pax in that it saves and restores file permissions (privileges), dates and times of creation and modification, etc. It will also overwrite existing files, unless overridden by the appropriate option. Good backup practice If at all possible, you should keep an up-to-date backup of everything on your working disks, so that if they should fail, you can restore absolutely everything to a new hard disk. A good but expensive and complex way of achieving this is to use disk mirroring (part of the standard RAID range). A much cheaper and simpler way of achieving this is to make frequent comprehensive incremental archives onto a special backup disk. Then, should disaster strike, you can restore whatever is necessary from those archives. Provided that they are updated relatively frequently, no disaster should ever require excessive repetition of work. Aside from the profound mistake of not making backups at all, the commonest faults are not making backups frequently enough, not making them complete, keeping increments but losing the base archive to which those increments are to be applied, and never practising a restore. As with all emergency measures, a backup-restore system must be practised before disaster strikes. If you worked in a building in which the fire alarms were never tested, would you trust them to work in a real fire? Yet, of the few users who make good backups, even fewer rehearse recovery from them. Volume structure The ideal 'safe' Mac OS X system will have access to three bootable systems: the main Mac OS X volume, a secondary Mac OS X volume which can be used as the startup volume in an emergency, and a volume with Mac OS 9.1 or later installed on it (that is useful in case you have difficulties restarting in Mac OS X). This may seem excessive, but Mac OS 9.1 and the main OS X systems can co-exist on a single volume, and the emergency copy of Mac OS X can be on the same (preferably external) disk containing backups. Make sure that you install the most recent releases of hfspax and your other recovery tools on both Mac OS X volumes. Make additional copies (e.g. on tape drives, CD or DVD media) of your archive files, hfspax, etc. In the event that your main Mac OS X volume is damaged or lost, restart from your emergency copy of Mac OS X and you can then initialise the main volume (or its replacement) and restore from your archives. You should also still be able to make a reasonable job of recovery if your emergency disk is damaged or lost. Most Macintosh computers are delivered with their hard disk initialised to a single huge volume. You will probably find it best, before installing anything else, to restart from your Mac OS Install CD-ROM and initialise a single hard disk into two or more volumes to support the above scheme. Alternatively, you could install a second hard disk (most suitable for desktop models with internal space), or buy an external disk from which you can restart your Mac. Spending a little on an extra hard disk is an excellent investment for the future, and much cheaper than the lost work that could result from a crash. Cautions and limitations hfspax comes without any guarantee or warranty of any kind. You use it at your own risk, and should you lose data as a result of a bug in hfspax, we can only offer to refund what you paid for it! If you have followed the recommendations above, the chances of a problem occurring when you are restoring for real should be extremely small. If you report problems that you encounter when practising restores (when they should not lose any of your data), we will do our utmost to identify them, and fix any bugs that may be responsible. However, before blaming hfspax, please take a little time to check that the problem is real, and did not arise because of a misunderstanding of the documentation. Again, we will do everything we can to assist you – our contact details are given below. Details of known limitations and problems for each release of hfspax are given in the file named ThisRelease.rtf. Darwin and Mac OS X Although Darwin is the open source core of Mac OS X, it has become clear that Darwin and OS X handle their file systems, resource forks, etc., very differently. Because of this, hfspax will not work in Darwin, and its approach is actually off the mark. If you have a Darwin system and Mac OS X running side by side, then you can quickly see how they work differently. Create a temporary folder, and copy into it a file that you know has a decent sized resource fork (under OS X, use Finder copy rather than Terminal). We will say, for the sake of this example, that file is myfile. Now, open a command shell, and cd to the folder. Try ls -la and see your file listed, but at a reduced size (as the resource fork size is not included, at least under OS X). Look for the resource fork using ls -la */..namedfork/rsrc and ls -la */rsrc Whilst the first should succeed in revealing info about myfile's resource fork under OS X, it will probably fail under Darwin. For Darwin, you should have more success with ls -la myfile/..namedfork/rsrc or ls -la myfile/rsrc Having assured yourself that there is a resource fork there, copy it using cp myfile myfiledupe Repeat the ls commands above, and under Mac OS X, you will see that the copying has stripped the resource fork. However, under Darwin, the resource fork should still be there. Amazingly, the Darwin source for cp does nothing special to handle resource forks – this is actually managed by the file system itself. We clearly need more information to explain these differences and their significance to applications, etc. Typical uses The following examples illustrate some common ways in which you can use hfspax from a command shell (Terminal). In each command, we include the v option which makes hfspax's output verbose. If you do not wish to see all the files listed in detail, omit the v character from the commands given below. Backing up To create an archive of the folder thisfolder under the name thisfolder.pax, type in the command hfspax -wv -f thisfolder.pax -x cpio thisfolder If thisfolder is not in the current path, you can either change your working directory with a command like cd /Users/Documents/ and then use the above command, or you can use a command like hfspax -wv -f thisfolder.pax -x cpio /Users/Documents/thisfolder The effect of these differs significantly when you come to unpack the archive: if you used cd to change directory, the unpacked archive will be reconstructed relative to your current working directory. If you used the full path name in the command as given immediately above, then the old directory will be completely reconstructed in its original location. It is important that you appreciate this fundamental difference: when unpacking, hfspax (like pax) will restore files to the path shown when you list the contents of the archive, relative to the current working directory (in the command shell). Listing archive contents To list the contents of the archive thisfolder.pax, type in the command hfspax -v -f thisfolder.pax Restoring To restore the files contained in the archive thisfolder.pax to their original locations, type in the command hfspax -rv -f thisfolder.pax Note how you can control whether the original directory is reconstructed, according to how you specify its original path name (see above). Volume backup To make a full backup of your active Mac OS X volume, you will need to create a series of pax archives to cover each of the folders. If you do not have Mac OS 9.x on the same volume, you can achieve this using the following commands (which assume that you are creating the archives at the top level of another volume called backvol): hfspax -wv -f /Volumes/backvol/Applications.pax -x cpio Applications hfspax -wv -f /Volumes/backvol/Library.pax -x cpio Library hfspax -wv -f /Volumes/backvol/Network.pax -x cpio Network hfspax -wv -f /Volumes/backvol/System.pax -x cpio System hfspax -wv -f /Volumes/backvol/Users.pax -x cpio Users hfspax -wv -f /Volumes/backvol/bin.pax -x cpio bin hfspax -wv -f /Volumes/backvol/private.pax -x cpio private hfspax -wv -f /Volumes/backvol/sbin.pax -x cpio sbin hfspax -wv -f /Volumes/backvol/usr.pax -x cpio usr hfspax -wv -f /Volumes/backvol/mach.pax -x cpio mach* Note how you access the other volume through its named entry in the /Volumes path: this is the standard UNIX way of accessing volumes other than the root (which appears at /). The final command backs up the Mach kernel files, which remain at the root level of the startup volume. You may also need to run the following line if you have the developer tools installed: hfspax -wv -f /Volumes/backvol/Developer.pax -x cpio Developer You may find it useful to back up the /dev folder. However, this may not be useful, or it may result in many errors, because of its special nature. If you do want to try backing it up, use something like: hfspax -wv -f /Volumes/backvol/dev.pax -x cpio dev Volume restore To restore a totally trashed Mac OS X startup volume, restart from another Mac OS X volume, initialise the disk, and allow the Mac OS X Install CD-ROM to install OS X 10.x. Then, make sure that hfspax is installed on the reconstruction disk, restart from it, and simply restore each of the .pax backups using a command like hfspax -rv -f /Volumes/backvol/Applications.pax Note that you have to do this from the disk to which you are restoring, or each archive will replace the files on the active or 'root' Mac OS X disk. You can work around this by creating the archives from within each directory, but this starts to get fairly complex. You can also use this sequence of commands to create a mirror of your Mac OS X startup volume on another hard disk, although you will need to recreate some links at the root level. Moving to a new Mac When you need to move all your work from one Mac to another, the easiest thing to do is a full backup (see above) onto an external disk, such as a FireWire hard disk. Put all the pax files there, and move the disk over to your new Mac. You will then want to select which files you want to install: a simple way of doing this is to cd to your Documents folder cd ~/Documents and then unpack each archive in turn into that location, using commands of the form sudo hfspax -rv -f /Volumes/backvol/Applications.pax (Note the use of sudo, see below.) You can then change the owner of folders as necessary, using something like sudo chown -R mynewusername Applications as appropriate. Then using the Finder (recall that command line cp will not preserve resource forks), drag the applications, folders, etc. into their new locations . Working incrementally You can use hfspax's command options to perform incremental backups and restore incrementally. To create an archive with just files modified since year 2001 month 08 date 10 hour 07 minutes 30, use hfspax -wv -f archive.pax -x cpio -T 0108100730/m foldertoarchive When you want to append those same files to the existing archive called archive.pax, use the -a option thus: hfspax -wv -a -f archive.pax -x cpio -T 0108100730/m foldertoarchive You can also use the -T option with a date given in the above format (yymmddhhmm, for details see the man page) to select those files to unpack with hfspax -r. If you want to unpack files into existing folders, then you should use the -k option, or hfspax will happily trash the existing files for you, and replace them with those it unpacks. You can combine the -k and -T (and other options) to produce quite powerful and selective commands, such as hfspax -rv -f archive.pax -k -T 0108100730/m which will unpack only those files modified after the given date from archive.pax, into the current working folder, but will not over-write existing files. sudo or su Mac OS X has many features of Unix, including strict limitations on privileges for users. Depending on whether the current user has admin powers, and the permissions set for folders and files, you may need to assume additional powers as a 'super user' before you can read or write them. Thus, you may find that you need to preface any or all of the above commands with the sudo command. You can also become the super-user ('root') with the su command. You should be extremely cautious about doing so, because you can rapidly cause all sorts of problems and damage unless you really – really – know what you are doing. If you do not know how to use sudo, then you should read the relevant section of a good Unix guide, and its man pages (man sudo). File naming: an important issue Mac OS X using an HFS+ volume has to cope with both Mac OS 9 and Unix file naming conventions. When an operating system refers to a file using its full path name (as hfspax has to do), it uses a separator character between each element in the full path name. For instance, /Users/me/Documents/test.rtf specifies the file test.rtf in the path /Users/me/Documents. Unix uses the '/' character as its separator, whilst Mac OS 9 uses the ':' character, e.g. HacHardDisk:Users:me:Documents:test.rtf If you create or keep files that include a separator in their name, this will confuse tools such as pax, as the name will be seen to contain part of the pathname as well. In OS X, this can happen if you use '/' or ':' characters in file names. This will cause hfspax to break, and its behaviour will then be unpredictable, and it will corrupt files. Currently, we do not know of a workaround to help this unfortunate situation. A more facile and friendly solution We are currently developing a $10 shareware Cocoa application (no command shell needed!) called BackXwing, which will encapsulate hfspax's power, features and flexibility in a friendly interface. Beta releases are starting soon. If you feel that you would like to encourage future development of hfspax and BackXwing, please visit Kagi and register your copy of BackXwing there. Further information The best book about backing up UNIX systems is: Unix Backup & Recovery, W Curtis Preston, published by O'Reilly, 1999, ISBN 1-56592-642-0 and Curtis Preston's website at http://www.backupcentral.com/ is well worth a visit too. Mac OS X assistance is available from many sites now, including http://www.macosxhints.com/ and the usual authoritative sites such as http://www.macfixit.com/ and http://www.macintouch.com/ hfspax and other backup tools are available from http://homepage.mac.com/howardoakley/ Bug reports and correspondence should be sent to [EMAIL PROTECTED] Notices & acknowledgements pax is Copyright (c) 1992 Keith Muller. Copyright (c) 1992, 1993 The Regents of the University of California. All rights reserved. In the development from pax to hfspax, valuable help was given by Alfredo "Fred" Sanchez, formerly of Apple Computer, who presented an invited paper on the mechanisms in Mac OS X for handling resource forks, at the USENIX meeting in 2000. Encouragement and alpha-testing were provided by my colleagues at MacUser (the original UK magazine of that name, from Dennis Publishing Ltd.), particularly Keith Martin, and a dedicated core of long-suffering friends. The changes made from pax to hfspax are Copyright © 2001 EHN & DIJ Oakley, all rights reserved – except that permission is given to use and to distribute hfspax freely subject to the following limitation. hfspax may not be included in any commercial product (for example, within a more substantial backup utility for which money is charged) or distributed in any commercial product (for example, a collection of software on CD-ROM) without the explicit consent of the copyright holder, EHN & DIJ Oakley. You are encouraged to produce and distribute scripts and other tools to help others use hfspax. However, if you wish to charge for packages that include hfspax, you must make arrangements with us over licensing details. Howard Oakley EHN & DIJ Oakley August 2001 (revised 16 August).
