First Look: The Linux-Based Paragon Rescue Kit for Mac OS X Lite

On May 1, 2008, at 10:27 AM, Joe Kissell wrote:

> I'm looking for feedback and opinions about a new Mac data recovery
> program that isn't actually Mac software at all - it's a bootable
> Linux CD:
>
> <http://db.tidbits.com/article/9598>
>
> Those of you who are so inclined, please consider checking out the
> software and sharing your impressions of this unusual approach here
> on the list.


I'll take a look, probably over the weekend. It should be noted that
HFS+ reading code has been around in Linux-land for a very long time.
For example, it came with the old mkLinux installation I had on my
8100 years ago. And it worked fine. (The 8100 is long gone.) At
that time, while there was writing code, it was hedged about with
warnings. The warnings are less strident in the Yellow Dog Linux I
still have installed in my almost unused 7300.

Whether the version used by Paragon understands extended attributes,
hard linked directories (totally foreign to Linux), and other modern
Apple extensions is another matter. There is no real reason why it
shouldn't.

Nonetheless, the approach seems surprising to me, too.

   --John (who wrote, in Apple ][ Pascal, a disk repairer for Apple's
SOS, back in the day--I was never courageous enough to release it
beyond the owner of a little Apple-store-in-the-back-of-furniture-
store, who had good luck with it.)

At 11:54 AM -0700 5/1/08, LewisGmail wrote:
>Joe said:
>>Mostly, however, I'm interested in getting feedback from other
>>TidBITS readers on both the concept of a Linux-based utility for
>>your Mac and the particular approach this tool is taking. Is it just
>>me, or is this a highly wacky - and somewhat disturbing - idea?
>
>It's probably not just you, but it is not at all a wacky or disturbing
>idea to me.

Doesn't bother me at all.
If I'm going to recover my boot disk, I will reboot off a DVD to do so.
(since I don't want to be running software loaded off that damaged boot disk).

On the other hand, rebooting my machine every time I want to make a
backup is *right out*.

On the gripping hand, if the disk recovery program is hard to use,
cryptic (requires me to know that /dev/en1 is probably my Airport or
asks me if I want to repair /dev/disk0 ) - then it's not going to get
used no matter what OS it runs on.
--
-- Marshall

Having something of an immediate need for a product such as this
(details to follow), I signed up for the beta and downloaded it. Just
finished giving it its first spin. I think it may be a useful
utility, but I haven't had any luck with it so far.

Here's the caveat: I tried it out on a Toshiba with a toasted HD that
belongs to one of my student employees. NTFS filesystem, WinXP
installed. The manual for Rescue Kit says it handles NTFS with full
read/write capability, so I thought it would be worth a shot. This
disk is too far gone for Rescue Kit to even see any files, however,
so, no dice.

I didn't find the interface to be too hard to discern, but I do have
some rudimental Linux chops already. Nevertheless, the only thing
that even looks like it might confuse a typical Mac "power user" (the
sort of person who would likely be using such a utility) is the
naming conventions for volumes- unix-type device designations (hda1,
sda1) rather than volume names. That's fairly annoying if you don't
know what it means. Aside from that, the file transfer dealy looks a
lot like some FTP clients do-- two main panes, source drive on one
side, destination on the other. Not too tough to intuit.

But then again, it didn't do beans to help in my particular
situation. If anyone knows a decent NTFS file-recovery program,
preferably free, email me off-list.

--
Greg Sigman, Senior Library Associate
Ohio University Music/Dance Library
sigmanohio.edu

A couple of years ago I saw a couple of generic Linux boot CDs working on Intel Macs - things should be even better by now: http://mugoo.eton.ca/smf/index.php?topic=1032.msg1710#msg1710

Since Linux has people excited about different file systems a generic boot/fix CD should be pretty possible. One CD that can fix just about any computer is a great idea.

If you think of it as an emergency boot disk, it does make sense.
Linux can be fit on a single DVD or even a CD and you don't have to
pay Apple licensing fees. The HFS+ format is well documented, and so
are all of Apple's extended attributes.

I can't see any reason why a Linux application couldn't to a good job
with working with a Mac disk. The problem would be the quirky
interface and whether Mac users can get use to it.

--
David Weintraub
qazwartgmail.com

Joe Kissell asked:
>Is it just me, or is this a highly wacky - and somewhat disturbing - idea?

Frankly, I have no idea why you would think this to be a "disturbing"
idea. Personally, I think it's a very clever idea.

I recently listened to a Podcast where a representative of - I think -
Prosoft explained that it was somewhat hard to get Apple to approve
third-party apps which contain bootable versions of OS X. In fact,
since Apple is often slow to approve new versions of OS X for such
applications, third-party devs sometimes can't offer bootable versions
of their disk tools for new hardware for quite some time. For example,
Prosoft's website has this to say about Drive Genius 2:

"As of February 2008, the Drive Genius DVD cannot boot some newer
model Intel based Macs shipped after June of 2007. As soon as Apple
provides third party developers with a Leopard (10.5) compatible boot
disc for these newer model Macs, we will produce a new Drive Genius
DVD."
<http://www.prosofteng.com/products/drive_genius_sysreq.php>

Going with a Linux kernel circumvents this issue and might allow
faster support for new hardware.

Is there a technical issue with this? My guess is that at least some
of these Mac-oriented recovery tools don't make extensive use of
Apple's HFS+ APIs anyways. After all, if there's something wrong with
a disk, chances are Apple's APIs won't behave in a predictable way.
Hence, missing out on these APIs might not be much of an issue at all.

Lukas

On May 2, 2008, at 7:33 AM, Lukas Mathis wrote:

> Going with a Linux kernel circumvents this issue and might allow
> faster support for new hardware.

I agree with you on the first point, but not on the second.

A year or so ago I installed Yellow Dog Linux on an old Powerbook just
to see what the then current YDL was like these days. Installation
was painless, but when I brought it up, wireless networking wouldn't
work. A few minutes with Google on my current OS X Powerbook located
a small C program that, when compiled and run on OS X, made a copy of
the binary driver for the wireless card and massaged it into a form
that YDL could use. So I compiled and ran the code, put the drivers
on a key drive, plugged it into my old Powerbook and installed them,
and I could then set up the network. (But sleep on the Powerbook
isn't supported at all by YDL.)

This is not a problem limited to Apple. Lots of hardware is
proprietary and the owners won't release enough information to enable
Linux developers to easily write drivers. Sometimes motivated
developers can reverse engineer drivers, but if a piece of hardware is
sufficiently obscure or new, it's unlikely that that has happened.
It's always seemed to me that Linux lags rather than leads in the
support of new hardware.

--
Paul Schinder
schinderpobox.com

> A year or so ago I installed Yellow Dog Linux on an old Powerbook just
> to see what the then current YDL was like these days. Installation
> was painless, but when I brought it up, wireless networking wouldn't
> work.

Yes, but you have to keep in mind that this is an emergency disk. WiFi
and sleeping and the webcam and all those other things don't have to
work. Linux just needs to be able to boot your Mac and access your
disks.

All those Macs which can't boot Prosoft's Drive Genius because Apple
doesn't release a bootable version of OS X? They boot Linux just fine.

Lukas

On Thu, May 1, 2008 at 2:54 PM, LewisGmail <gkremegmail.com> wrote:
> Since it doesn't write to the source drive

The spec and actuality are different things. :)

> (and really, that is trivial to verify)

Not at all; even such a special-purpose tool has many potential paths
through the code.

> there's essentially no risk.

IFF there are no bugs and what we're hearing so far does not - yet -
inspire confidence in the quality of the code.

On Thu, May 1, 2008 at 3:08 PM, <johnbaxterlistsmac.com> wrote:
> Whether the version used by Paragon understands extended attributes,
> hard linked directories (totally foreign to Linux), and other modern
> Apple extensions is another matter.

Exactly; HFS hasn't been standing still.

> There is no real reason why it
> shouldn't.

No, but with my data anyway, I prefer to consider the other side of
the coin; I want to see some reasons why it *should* handle the
specifics of HFS well. :)

Dear forum visitors,

We, Paragon, have a great experience in backup/restore software for PC. So, we decided to transfer it to the Mac community. This is our first beta of a backup/restore solution for Intel-based Macs. Why Linux? We have been using Linux for our backup/recovery solutions for 10 years already and transferring our source code to Mac OS may take several months of complex tasks. How do we deal with Apple-specific issues like HFS+? We wrote our own HFS+ driver as well as NTFS one. Please note, we use our unique and proven UFSD (universal file system driver) technology to write such file system drivers.

Thank you very much for your remarks regarding program's user interface. I hope we will be able to improve it and release Rescue Kit with a more Mac-like interface.

Best regards, Anatoly. Paragon.

On 04/05/2008 7:53 AM, "Marc Farnum Rendino" <mvgfr1gmail.com> spake thus:

>> (and really, that is trivial to verify)
>
> Not at all; even such a special-purpose tool has many potential paths
> through the code.

No write calls allowed within code that deals with file system recovery.
Easy to verify. Better yet, wrap all access to disk inside a driver-level
lockdown. Then you only have to worry about bugs in the driver (but then
that's true regardless of the operating environment). I suspect many disk
recovery tools use low level direct disk access through the hardware driver,
and then attempt to apply the file system view on top of that.

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://xri.net/=nigel.stanger

>No write calls allowed within code that deals with file system recovery.

There HAVE to be write calls. In this case, for writing to another
disk. In others, to try to fix the original disk.

Either way, there are write calls. And those, if mistaken, can worsen
a problem.

>Easy to verify. Better yet, wrap all access to disk inside a driver-level
>lockdown.

And this company has written its own HFS+ drivers. Should we trust those, yet?
--
=Alex Hoffman
Leadership, Policy & Politics
Teachers College, Columbia University

Ah; I see what you mean - easy [to confirm operation are read-only]
for the developers and some of us in a position to examine the code.

Not so easy for the rest of us, though we can rely on reports from the former.

On 5-May-2008, at 11:10, Alexander Hoffman wrote:
>> No write calls allowed within code that deals with file system
>> recovery.
>
> There HAVE to be write calls. In this case, for writing to another
> disk.

Trivial to mount on FS with a RO driver and another with a RW driver.

> In others, to try to fix the original disk.

This is not a disk REPAIR tool. This is a disk RECOVERY tool. No
repairing will be done.

> And this company has written its own HFS+ drivers. Should we trust
> those, yet?

I feel safe trusting nearly anyone to write a RO driver and have it be
really read-only. Am I going to use the beta to recover crucial
files? Unlikely. But that would be true regardless of vendor. Would
I use the beta to experiment with a 'lost' drive I don't really care
about? Yeah, sure.

I don't know why there should be more distrust in a third party Linux
based tool for HFS recovery than a third party Mac OS X based tool for
HFS recovery.

The OS of the tool shouldn't be an issue. There maybe many reasons why
Paragon chose Linux: Familiarity with other versions of its tool, no
license worry about the OS for the tool. Ease of getting a bootable CD
that the tool can use, etc.

The question is really one of utility. Does the tool work and how easy
or hard it is to use? A Linux based tool does not have to be
confusing, and could automate such things as finding WiFi devices,
etc. The interface will be different from standard OS X, but then we
all should be use to different user interfaces by now.

I wouldn't count anything against the tool just because it uses a
different OS. The only question is one of ease of use. Obviously,
since you have to reboot to use the tool, I wouldn't consider a Linux
tool for day-to-day activities. But, if I have a sick hard drive, and
I can't boot into OS X, I would have no issues with a Linux based
tool.

There are problems with Paragon's Rescue Kit, but it is mainly in the
deficiencies in the beta version interface and not necessarily with
the fact that it uses Linix vs. OS X. When you need to recover a sick
hard drive, you'll be using a tool that you don't use every day, so it
should help you as much as possible with as little configuring as
possible. You are also in panic mode since your life now rests
precariously on the information stored upon a shredded disk. You want
a tool that works without being confusing.

It sounds like Paragon's Rescue Kit needs some more work, but I
wouldn't count it out just because it is Linux based.

--
David Weintraub
qazwartgmail.com

On Wed, May 7, 2008 at 6:17 AM, David Weintraub <qazwartgmail.com> wrote:
> I don't know why there should be more distrust in a third party Linux
> based tool for HFS recovery than a third party Mac OS X based tool for
> HFS recovery.

Because HFS is foreign to Linux, that's all.

> The OS of the tool shouldn't be an issue.

Absolutely.

> There maybe many reasons why
> Paragon chose Linux: Familiarity with other versions of its tool, no
> license worry about the OS for the tool. Ease of getting a bootable CD
> that the tool can use, etc.

Absolutely - except the familiarity reason. That gets into
laziness/inertia and is not a good indicator.

> A Linux based tool does not have to be confusing

No, but apparently - so far - this one is.

> The interface will be different from standard OS X

Different is OK - maybe necessary in this case, maybe desired.

However a poor UI is not OK.

> There are problems with Paragon's Rescue Kit, but it is mainly in the
> deficiencies in the beta version interface

A quality UI is not slapped on in the final version, it is designed in
from the start; it is central to the operation, not a skin.

> When you need to recover a sick
> hard drive, you'll be using a tool that you don't use every day, so it
> should help you as much as possible with as little configuring as
> possible. You are also in panic mode since your life now rests
> precariously on the information stored upon a shredded disk. You want
> a tool that works without being confusing.

Very good points; the requirements are perhaps even stronger in this
category, since not only are the stakes high, but the user's emotional
state is at a higher level.

> I wouldn't count it out just because it is Linux based.

Absolutely; it's a great idea.

- Marc

On 7 May 2008, at 11:39, Marc Farnum Rendino wrote:

> Because HFS is foreign to Linux, that's all.

A decent disk recovery tool will not be using the OS filesystem
drivers/code anyway. These are designed to work with a disk in good
health, not a failing one. Thus using them is going to achieve no more
than can be done by booting with your OS X install disk and having a
hack around in the Finder.

Given that the vendor is writing their own drivers, having access to
the native OS is of little use. In this case, Linux is less foreign to
the vendor and so a better choice.

I have used Linux boot disks to repair/retrieve data from damaged
Windows boxen in the past without it causing me any worry. In fact I
generally feel more confident using Linux than Windows in these cases.

It is remarkable how quickly we've forgotten that OS X is UNIX and
thus a cousin of Linux (a testament to how well Apple have hidden
what's going on underneath).

The only pertinent question here ought to be: how well does it do the
job? I'm afraid, in common with most of the replies here, I have no
useful information to add to that question.

What I would add though is: roll on ZFS! Having spent some time
studying this filesystem in detail recently, I look forward to having
it fully supported in OS X and stopping worrying about filesystem
corruption. The amount of thought that has been put into data
integrity by Sun is remarkable.

Jonathan

On Wed, May 7, 2008 at 11:33 AM, Jonathan Hogg <jonathanonegoodidea.com> wrote:
> A decent disk recovery tool will not be using the OS filesystem
> drivers/code anyway...

I think we're getting off in the weeds here, arguing things that are
associated, but not the same or even directly connected.

Let's see what the code itself does. :)

- Marc

I downloaded and trie Rescue Kit, but I was disappointed in that it
failed to mount or see any external Firewire disks. It seems to not
work with Firewire drives. I have one that I am trying to see if I
can copy the files on it before I replace the internal 120GB ATA drive
that has gone bad. I can sort of mount the 4 partitions on it. Disk
Warrior seems to want to take several hours or days to rebuild the
directories, and I was hoping this program might work faster. Nothing
crucial, (classic files) but I would like to see if I can rescue any
of the files.

Michael Logue