1 Topic by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Topic: Have you had a good or bad experience with Dev->Attempt Data Rescue?

We would like to hear your thoughts.

A. Should we continue to provide the Attempting Data Rescue feature?

OR

B. Remove it entirely because of increasing difficulties of keeping it fully functional on current Linux distros.

Some support challenges we face are:

- Uses unmaintained gpart
- Testdisk is arguably better and actively maintained
- Some poor experiences reported by users: 1, 2, 3, 4, 5
- Lack of progress indicator with exceeding long disk scan times
- Difficult and time consuming to test
- Lack of interest

Your comments would be appreciated.

Sincerely,
Curtis Gedak and Mike Fleetwood

2 Reply by mfleetwo

  • mfleetwo
  • Developer
  • Offline
  • Registered: 2012-05-18
  • Posts: 477

Re: Have you had a good or bad experience with Dev->Attempt Data Rescue?

A few days ago I had this conversation on the GParted IRC channel:

H*****s wrote:

hey there! I have a small question: I'm trying to recover my partition table by scanning the entire disk. It says it will be slow, which I understand. But now it's scanning and I don't see any disk activity LED blinking, is that expected?

mfleetwo wrote:

Yes.  Device > Attempt Data Rescue is using the "gpart" command under the hood.  I expect it will be using 100% CPU and reading your disk only occasionally.
We are considering removing this functionality from GParted.  http://gparted-forum.surf4.info/viewtopic.php?id=17992
If it doesn't complete in 24 hours then kill "gpart" process.
Consider using Testdisk instead to scan for partitions.  https://www.cgsecurity.org/wiki/TestDisk

H*****s wrote:

thank you @mfleetwo. I ended up using Testdisk indeed. Very oddly, it couldn't find *anything*, not a single signature of an EXT4 partition and/or LVM, I suspect this SSD is completely dead even though it shows the correct capacity and so on. But anyway that's beyond the scope of this channel, thanks for your help!

The user may not of had any file systems to find, however they still experienced the "gpart" process using 100% CPU for hours on end while hardly ever reading from the drive.

3 Reply by erw1 (edited by mfleetwo 2022-06-18 23:00:10)

  • erw1
  • New member
  • Offline
  • Registered: 2022-06-18
  • Posts: 1

Re: Have you had a good or bad experience with Dev->Attempt Data Rescue?

It's been a few hours since I started "Attempt Data Rescue" on a 1TB external HDD, and it keeps searching for filesystem on /dev/sdc (bottom echo area). CPU=0% according to task manager. Should I quit?

Here are snapshots:

Screen shot of Task Manager app
Screen shot of GParted app

Edit: Replace text with actual URLs to images

4 Reply by mfleetwo

  • mfleetwo
  • Developer
  • Offline
  • Registered: 2012-05-18
  • Posts: 477

Re: Have you had a good or bad experience with Dev->Attempt Data Rescue?

@erw1
The process using the CPU time will be gpart not gparted.

I guess that it will take more than 24 hours for a 1 TB drive.

The expedient course of action is to kill the gpart process and use TestDisk instead.  (See link in earlier messages).

5 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: Have you had a good or bad experience with Dev->Attempt Data Rescue?

The "Attempt Data Rescue" feature has been removed with the release of GParted 1.6.0 on February 26, 2024.