SuperDuper's free trial only does normal copies and file updates from one drive to another. So it's like a gui on top of rsync.
Disk Warrior might do what I want -- it claims to -- but at $120, non-refundable, it's out what I'm willing to pay. Super Duper's website makes no claims about being able to restore dead drives, or fix catalog errors, etc. So I'm looking at a .sparsebundle, that is fully readable (bands, etc), containing a broken file system that fsck/disk utility cannot fix, and cannot even attach -readonly. And I'm looking at hfs+ and thinking "unix's file system never got into this bad of a problem, even if you wound up with hundreds of directories in lost+found without any hirearchy, and usually would mount readonly in the worst cases." In fact, just in case there was some issue with the non-fixableness being related to being a time machine non-writable image somehow, I tried doing it with shadow. bash-3.2# hdiutil attach -nomount -shadow ~/tmp/shadow2.hdiutil TimeMachine.sparsebundle/ /dev/disk9 GUID_partition_scheme /dev/disk9s1 EFI /dev/disk9s2 Apple_HFS bash-3.2# diskutil repairVolume disk9s2 Started file system repair on disk9s2 TimeMachine Checking file system Checking Journaled HFS Plus volume Detected a case-sensitive volume Checking extents overflow file Checking catalog file Invalid sibling link Rebuilding catalog B-tree The volume TimeMachine could not be repaired Volume repair complete Updating boot support partitions for the volume as required Error: -69845: File system verify or repair failed Underlying error: 8: POSIX reports: Exec format error bash-3.2# Looks like it's a simple case of "$120 to recover is more than I can afford/value the recovery". On 2020-01-23, at 4:23 PM, Macs R We <[email protected]> wrote: > Looks like my information was old. Version 4 couldn't do it (even after they > claimed it would); version 5 apparently handles it well. Guess I stopped > trying it after version 4 yelled at me. > > Another source says: > >> SuperDuper will make a file-level copy, handling multi-linked files >> correctly, and will produce a copy without catalog damage even if the source >> has catalog damage. (But if the source catalog is damaged, the copy may not >> finish, and even if it finishes the new copy may have other non-catalog >> inconsistencies that make it unusable.) > > You may want to try that, especially since I think it has a free trial. > > >> On Jan 23, 2020, at 4:21 PM, Matt Penna <[email protected]> wrote: >> >> I’m curious about this because DiskWarrior works fine for me on Time Machine >> volumes (but I’ve never tried it on a Time Machine sparsebundle). >> >> The only trouble I had with DiskWarrior on Time Machine drives was when it >> was a 32-bit app and could not allocate enough memory to hold all the file >> system structures—a showstopper with my Time Machine drive that at the time >> had a 17GB B-tree and that definitely would not fit into the 4GB 32-bit RAM >> limit. >> >> Since going 64-bit in late 2014, DiskWarrior should work on all Time Machine >> volumes. >> >> In an ironic reversal with modern Macs, DiskWarrior can now ONLY work on >> Time Machine drives; APFS-formatted drives drives are not supported with >> current versions of DiskWarrior and Time Machine drives are still HFS+. >> (Alsoft says DiskWarrior APFS support is coming soon, now that technical >> specs for the file system have been finalized, though APFS is ostensibly >> robust enough to not need much fixing. I know, I know…) >> >> Matt >> >>> On Jan 23, 2020, at 1:39 PM, Macs R We <[email protected]> wrote: >>> >>> Although all of this is true, as it turns out, I know of only one disk >>> management tool that will even attempt to repair a Time Machine volume, >>> because the volume architecture is so baroque -- and that is Disk Utility. >>> If you try to repair the volume with Disk Warrior, it will flat out tell >>> you, "this is a Time Machine volume, and I don't do those." You have to use >>> only Disk Utility, not fsck. If DU can't solve the problem, it can't be >>> solved. >>> >>>> On Jan 23, 2020, at 11:31 AM, Matt Penna <[email protected]> wrote: >>>> >>>> On Jan 23, 2020, at 1:25 PM, Michael <[email protected]> wrote: >>>>> >>>>>> On 2020-01-23, at 10:23 AM, Matt Penna <[email protected]> wrote: >>>>>> >>>>>> If you have DiskWarrior, I would give that a try. I believe it works on >>>>>> disk images and sparsebundles. >>>>>> >>>>>> Matt >>>>> >>>>> I do not have disk warrior. >>>> >>>> Unfortunately, whenever a drive or image is not reparable like this, I’ve >>>> always had to resort to a 3rd-party tool to fix the file system; the >>>> built-in tools are not very robust. Perhaps someone else will have another >>>> suggestion. >>>> >>>> It’s always been baffling to me that 3rd parties write better fix-it tools >>>> than the people who write the OSes. This has been a problem for over 30 >>>> years and it’s still as unsolved as ever, even if the file systems are a >>>> lot less fragile than they used to be. >>>> >>>> Matt >>>> _______________________________________________ >>>> MacOSX-talk mailing list >>>> [email protected] >>>> https://www.omnigroup.com/mailman/listinfo/macosx-talk >>> >>> _______________________________________________ >>> MacOSX-talk mailing list >>> [email protected] >>> https://www.omnigroup.com/mailman/listinfo/macosx-talk >> >> _______________________________________________ >> MacOSX-talk mailing list >> [email protected] >> https://www.omnigroup.com/mailman/listinfo/macosx-talk > > -- > Macs R We -- Personal Macintosh Service and Support > in the Wickenburg and far Northwest Valley Areas. > http://macsrwe.com > > _______________________________________________ > MacOSX-talk mailing list > [email protected] > https://www.omnigroup.com/mailman/listinfo/macosx-talk --- Entertaining minecraft videos http://YouTube.com/keybounce
_______________________________________________ MacOSX-talk mailing list [email protected] https://www.omnigroup.com/mailman/listinfo/macosx-talk
