Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


wildthing last won the day on July 19 2012

wildthing had the most liked content!

Community Reputation

1 Neutral

About wildthing

  • Rank
  1. Yep, that might work as well, I haven't tried that. I only have one Mac, however when I clone my system HD using SuperDuper, the clone is bootable. So another solution might be to boot from the cloned HD, and then burn the primary HD to disc. I haven't tried that either. I've only tried burning the cloned HD to disc while booted into the primary HD. But if it works, then the general principle would be as you say, avoid burning from the HD you booted into.
  2. Thank you for your reply Eugene. Well it depends what we mean by "backup", but burning data discs (as opposed to video/audio) is one of Toast's advertised features and I would assume people do this for backup/archiving purposes. There are other applications specifically designed for backup – but none of them can back up to optical discs as far as I'm aware. All the consumer backup Mac OS X applications I've tried/used either back up to hard disk, or the cloud. Before I bought Toast, I did actually try using Mac OS X's built-in data disc authoring capability in Finder.app, as this worked fine for me previously with data CDs and DVDs. However it would not work with my Blu-ray drive (a Pioneer BDR-206DBK in a USB enclosure). It recognized the drive and said "Writing track 1" for about 10 minutes and then ejected the disk saying: "The disc can’t be burned because the disc drive is not accessible (error code 0x80020020)." When I got in touch with the vendor of the drive, a data archiving specialist (http://imagestore.co.uk), they were very helpful and they basically said all their clients use Toast for authoring data Blu-ray discs on the Mac platform. This is how I came to use Toast — and for all its faults, Toast did enable me to overcome this particular error. So — it looks like if you want to backup/archive data to Blu-ray on the Mac OS X platform, Toast is the only game in town right now. There still is — it's called "Get Backup 2" from Belight Software. When I first experienced the Toast issues, I wondered if I should be using Get Backup 2 instead. There are actually a total of 7 apps in the Toast 11 Titanium bundle but no obvious place to find an overall summary of what each app does, or guidance along the lines of "if you're trying to do task X, use app Y". So I didn't know if I should be using Toast or Get Backup 2 to backup my Mac home directories. However the Get Backup 2 user interface specifically mentions e-mails and other items which are stored in Mac OS X system folders, so I thought — maybe this product is actually designed to be able to deal with the system folders within Mac OS X home directories? The bundled version is "Get Backup 2 RE" which does not natively support burning to optical discs, however it can integrate with Toast to burn optical discs. You can also upgrade to the full version for $9.95 which natively supports burning backups to optical discs (http://www.belightso...oxioedition.php). I tried both, and in case it's of any help to anyone else thinking of going down this path, here are my experiences using Get Backup 2 (both RE and Full versions) to back up Mac OS X home directories to optical disc, which I tried in order to overcome the -43 errors I was getting with Toast. This is the same text I reported to technical support in late 2011, based on Get Backup 2 version 2.4.7. Some of these issues may have been fixed since then, although I'm doubtful. 1. The Toast start-up wizard prevents Get Backup 2 RE from launching toast. When you configure Get Backup 2 RE to use Toast to burn a disc, it fails to work at all if the Toast start-up wizard is enabled. Unfortunately the start-up wizard in Toast is enabled by default, so with the default settings it doesn't work. You have to disable the Startup Wizard in Toast, before Get Backup is able to launch Toast to burn a disc. 2. Get Backup 2 RE fails preserve the correct disc name when it invokes Toast. For example, if you carefully name your backup "BD-R-2011-09-11a" in Get Backup, then when it launches Toast the disc name becomes "Backup Disc 1", and there's apparently no way to change it. 3. Get Backup 2 RE dumps all your data in a single gigantic tar file, which Toast then burns to disc. For me, this is not acceptable — I don't know how resiliant the "tar" format is to corruption; for all I know one small corruption on the disc could make the entire tar file unreadable. I want individual files to remain as individual files on the disc itself in an HFS+ filesystem, as with Toast. 4. Get Backup 2 Full version does not support native burning to Blu-ray discs. After through the whole "Preparing" and "Building" process, it then says: "The inserted disc is not a CD or DVD". For this reason, the $9.95 upgrade (paid to Belight, not Roxio) was a complete waste of money for me. At this point I gave up on Get Backup 2 entirely, and went back to Toast, and then I eventually found the workaround to the -43 error in Toast, described above. Thanks, this is useful — and also good to know I'm not the only one suffering.
  3. For some time I've been using/attempting to use Toast to make backups of my Mac OS X home directories to Blu-ray data discs. The reason for wanting to make a backup of entire home directories is that the OS X system folders within the users' home directories contain important stuff like e-mails, bookmarks, calendar, address book, as well as hidden application data and preferences and so on -- naturally, stuff you'd want to back up. Along the way I've come across many different issues and some workarounds which I thought I'd share on here. Some of these are known and previously discussed issues (that is, they're known on these forums, not apparently to technical support). 1. Random "-43" errors while trying to backup home OS X directories While trying to backup Mac OS X home directories, I was getting random "-43" errors, especially for files in the user's "Library" system folder, for example: The file "com.apple. …… .plist" could not be accessed (Data fork, -43) Result Code -43 The file "8B554403-AFA1-4F72#11CD138.data" could not be accessed. (Data fork, -43) Couldn't complete the last command because a file couldn't be found. Result Code = -43 I found that these -43 errors are all over the Roxio support forums with no solution. Creating a disc image or temporary partition did not help. I tried speaking to Roxio support but they didn't have any idea, nor could they tell me whether Toast officially supports backing up Mac OS X home directories or not in principle. Workaround: I eventually managed to workaround this issue by using the Mac disk-to-disk backup application SuperDuper! (http://www.shirt-poc...com/SuperDuper/) to clone my system HD to another backup HD, and then using Toast to burn a BD-R from the backup HD, instead of the original HD. I suspect this may work because SuperDuper excludes a whole bunch of transient and temporary system files that cannot be (and don't need to be) backed up - you can see that from the SuperDuper logs. Maybe Toast just isn't smart enough to do this on its own. 2. The "hanging at 99%" bug Sometime later I updated Toast from 11.0.4 to 11.0.6, and then tried to make another backup of my home directory to BD (of course using the SuperDuper clone of my home directories, rather than the actual live home directories, to avoid the -43 error). Then, I repeatedly got the "hanging at 99%" bug where it writes up 99% progress and then just hangs. Even when I tried copying to a disc image (.toast file) instead of an actual blu-ray disc, it still hung at 99%. Again I find that this issue is all over the forums, with no real fix. 3. Verification errors with the 11.1 beta So to avoid the "hanging at 99%" bug, one of the threads suggested that I try the Toast 11.1 Beta, so I downloaded and installed the beta 11.1.0a1(35) from the link given in that forum thread, and this time was able to burn the entire disc successfully - no hanging at 99% - however, it failed on verification with the following error: Mismatch at byte 0/sector 5391379. Verification failed. At first I thought this was due to bad media, but then this happened two more times - generating 3 consecutive coasters, each with the exact same verification error. I hardly ever got verification errors with 11.0.4 or 11.0.6 - certainly never 3 in a row - so I concluded this MUST be an issue with the Toast beta, and not with my media. Workaround: In the end I resolved this by downgrading(!) to 11.0.4. One of the forum threads said that the "hanging at 99%" issue did /not/ occur with 11.0.4, and that it was an earlier bug which actually re-appeared in 11.0.6. So I actually managed to avoid both the "hanging at 99%" error (which occured with 11.0.6) and the verification errors (which occured with the 11.1 beta) by downgrading Toast to 11.0.4. Surprisingly, the Roxio downloads page shows 11.0.4 is the only version there. I'm not sure why that is, seeing as 11.0.6 is the latest version according to the "Check for Updates" within the app itself. But anyway, this enabled me to "downgrade" my Toast installation to 11.0.4. This has finally allowed me to burn my home directory to BD again. So, yes, I eventually got it working again in the end. 4. Toast can only burn files belonging to the user who is currently logged in This is not a bug, more a feature request. I waste a lot of disc space because I could fit multiple users home directories on one BD, but I can't do this easily because Toast doesn't support it (it gives permission errors if you try). Other backup tools don't have this limitation. For example, I use SuperDuper! and JungleDisk which can both see ALL users' files and back them up. I'm assuming they install themselves with a form of run-as-root (a.k.a. setuid) privilege so they can backup files belonging to all users on the system. I know that SuperDuper backs up to disk, and JungleDisk backs up to the cloud, whereas Toast backs up to optical media. That's not the point; they're all backup tools, and the others have this feature whereas Toast does not. As a backup tool it would be nice if Toast could do this. Just a thought. Tech support: intense frustration I spent many hours dealing with the bugs and issues but I wasted even greater number of hours speaking to Roxio technical support which was really one of the worst tech support experiences I've ever had in my life. I know this is probably typical for many tech support these days, but these guys just bombard you with an endless sequence of almost completely random "try this" suggestions most of which bear no relation to the actual problem. They never show any inkling that part of their job might be to report bugs to their engineering team so they might eventually get fixed. The future I doubt if I can use 11.0.4 forever - at some point I'll probably need to upgrade. If anyone from Roxio reads this: it would be nice if a future version of Toast doesn't have these bugs, and can be used to backup Mac OS X home directories?
  4. Yes, although according to the Wikipedia HFS+ page, the data is stored there only if they're inline data attributes, while for other data types it holds pointers to the blocks that hold the actual data. But we're straying too far into the internal implementation details of HFS+ - it should be of no concern to us where HFS+ physically stores the data; what matters is that logically speaking, Mac OS X "extended attributes" are metadata associated with each individual file. Also "file attributes" is an ambiguous term, I think we're talking about OS X "extended attributes" which were introduced in Tiger. Not quite - according to the following article, resource forks used to be a separate fork, but this implementation has now been phased out, and now some of the data that was in the old resource fork is now stored in the data fork (i.e. is part of the file and affects the file size), while other resource fork data is now stored as an extended attribute under the key “com.apple.ResourceFork” (which, like other extended attributes does NOT affect the file size): http://jonsview.com/mac-os-x-resource-forks. Anyway, interesting as this is , resource forks aren't the issue in my case, because is seems that Toast is preserving the “com.apple.ResourceFork” extended attribute. What Toast is not preserving is the "com.apple.TextEncoding" extended attribute. I'm not sure why you'd need to do that. The source and the destination are both HFS+ already, it should just work. I might raise a Roxio support request / bug report, just to see what happens.
  5. Thanks - that's interesting. I did some experiments with the "xattr" command and found my original text files do seem to contain some extended attributes which Toast did not preserve. For example, on this text file which happens to be called "useful" there's an extended attribute specifying the encoding: $ xattr useful com.apple.TextEncoding $ xattr -p com.apple.TextEncoding useful utf-8;134217984 But the same file on the BD-R burned by Toast doesn't contain any extended attributes: $ xattr useful $ I'm pretty sure Mac OS X extended attributes are a type of metadata stored as part of the file itself, not in some central look-up table. Strangely, there are some other extended attributes which Toast does seem to be preserving: if I select just one source file in Finder and click Get Info > Open With and choose a different text editor e.g. TextWrangler.app - in other words change the file association for just that one file, not the default for its file type - then the file acquires a new extended attribute it didn't have before: $ xattr test com.apple.ResourceFork Now, I know resource forks are deprecated and Apple are moving everyone to using filename extensions instead - I'm sure you're right on that. Nevertheless I happened to have some mp3's which have per-file assocations, and this time Toast successfully preserved these and other extended attributes in the BD-R. On one mp3 I get the following result on the original file and on the optical disk: $ xattr song.mp3 com.apple.FinderInfo com.apple.ResourceFork Still, my text files don't have either of these extended attributes - they just have one called "com.apple.TextEncoding". I wonder if _this_ is how Mac OS X knows they're text files and associates them with TextEdit? In general, I was under the impression that other types of extended attributes (besides resource forks) were NOT deprecated and Mac OS X uses them for a lot of cool things, such as remembering that a file might be unsafe because it was downloaded from the internet, etc. I thought it was just resource forks that are deprecated, which are just one type of extended attribute (but my understanding could be completely wrong.) For this reason my expectation would be for Toast to simply preserve ALL extended attributes, so I'm not sure why it hasn't preserved "com.apple.TextEncoding". Still, not a big deal. Thanks, this helps.
  6. Hi, I just purchased Toast 11 for making BD-R data backups, and made my first disk this morning. I selected format "Mac Only" to ensure it preserves all the file metadata and extended attributes etc. On my original disk, I have a lot of text files with no filename extension e.g. "car" (not "car.txt"), which appear in Finder with a document icon. If I right click one and choose Get Info, the file type is shown as "Kind: Document" - and if I double click it opens in TextEdit.app. These files were created simply by saving from TextEdit with that filename. However after doing the backup, the same files on the BD-R have a black Unix terminal icon; if I right click and choose Get Info, the file type is shown as "Kind: Unix Executable File" - and if I double click it opens in Terminal.app and then immediately closes. Of course I can open it in TextEdit by right clicking and choosing Open With > TextEdit, but then I find it's not displaying correctly, for example a bullet "•" is displayed as "‚Ä¢", which suggests the character encoding has got lost as well as the file type. By choosing File > Save As I can see that on the original file, the character encoding was "Unicode (UTF-8)", but on the BD-R backup it's changed to "Western (Mac OS Roman)". Can someone tell me what I'm doing wrong? I thought by choosing "Mac Only" in Toast, I'd get a filesystem formatted with "HFS+" a.k.a. "Mac OS Extended", which is identical to my source data, with all my filesystem metadata (extended attributes, resource forks, etc) preserved, but this isn't happening.