Different results based on which operating system (q)photorec is run (linux vs windows)

[kennysuper]

Hello!

I installed ubuntu linux on my working and in use (with data on it) windows 2 TB drive
(GPT, 1 boot partition + 2 main NTFS partitions, one system (C:, roughly 300 GB) and a data partition (roughly 1700 GB).

After that i ran qphotodisk from another fedora linux computer (with a recent kernel, meaning the hopefully* latest ntfs-3g driver).

It recovered around 95 GB of data (some files were from the newly installed ubuntu,
but some were I think from the previous system browser's cache and some python files which were definitely mine eg. written by me
(didn't find yet ant of my pictures and other docs).

But now I am doing the same from windows.
One Caveat: Every now and then the searching stops and i have to start from the last sector. I am following this post.
Meaning the first time i started from qphotorec it stopped/froze at some point so i shut down the program,
go into the last directory, check the last file name (which is supposedly the last point to where qphotorec got,
so I edit the photorec.ses file like this (like in the tutorial from the above link):

Code: Select all

#1688699485
\\.\PhysicalDrive0 partition_gpt,255,blocksize,1024,fileopt,options,paranoid,keep_corrupted_file_no,wholespace,search,status=ext2_off,{FILENAME OF LAST FILE EXCEPT THE "F" AT THE FRONT},inter
{FILENAME OF LAST FILE EXCEPT THE "F" AT THE FRONT}-3907029167

The 3907029167 is the total amount of sectors? or smth (meaing 2 TB).
Then I start the program not from qphotorec but photorec, because qphotorec does not ask yout to start from previous session (bug or a feature ).
photorec.exe asks me to start from previous session - i say yes, select the same destionation as before and wait until the above happens again.
It is annoying but my question is if this is correct
(meaining i dont miss any files) and if does this hurts/changes the operation as if it would just run from beggining to the start?

Anyway the thing is that and there seems to be some more files when run from windows?
So I checked the "recovery destination" folder size and it is 250 gigs?
But then I find out that my progress has stopped somewhere in the middle
and the last folder contains two files (some random xml) and a 212 GB big .XZ file.
I tried to decompress it with 7-zip but I am yet unsuccessful (meaning that the rest of the fiels are for now around 38 GB (from 250GB)?
But also when i look at the files from the beggining the new destination (qphotorec being run from windows - from now just from windows) there are a few more files in the directories,
that are not in the destionation (run from linux - from now just from linux). If I search for certain files from recup_dir.1 (windows) I can not find them in the recup_dir.1 from linux.
I also saw that the linux files sometimes some files contain some or whole of their filename,
while on windows none of the files contain anything besides f + location + file extension.
Also some files from linux had the file extension not appeneded at the and with period, but in the end of the filename separated by underscore...

So I just wanted to clarify:
Is it possible that the program has different results if run from linux than from windows (ig with thsi case now only for ntfs drives) And why, how to fix it??

Any suggestions/ ideas/ questions are welcome. Thanks!

[recuperation]

Of course the results may be different.
You did not even bother stating the Windows operating used, naming the two versions of PhotoRec in question.
You are operating Photorec out of your disk containing a running operating system. Furthermore you did not indicate that you were taking any precautions to ensure complete shutdown.

Run the same version of Photorec under Linux and Windows on a different machine and attach your suspected failed disk to it, p.e. via USB.
See what that gives.

Furthermore, when dealing with a broken disk you risk yielding a diminished output on each additional run.
Better duplicate the drive using ddrescue as described in the manual.

[kennysuper]

You did not even bother stating the Windows operating used, naming the two versions of PhotoRec in question.
You are operating Photorec out of your disk containing a running operating system.

Okay sorry, I did not make myself clear. I hope this will be better: I have a laptop with two drives.
One is an active windows install as said with two main partitions (system and data (300 GB + 1700 GB = 2 TB)). The other drive is empty.
I wanted to install ubuntu on the empty drive, but I selected the wrong drive in the installer (Yes I am an idiot) so
I installed ubuntu on the active windows drive with my data.
but than as soon as I have realized what I did, I removed that ubuntu formated disk with data ("data disk" from now on) from my computer.
Then I installed fedora linux on my other (empty) drive, and a Windows To Go on a USB.
Only after that I placed my SSD disk in the primary SATA slot in my laptop.
Then i first ran the latest stable version of qphotorec (7.1) on my fedora linux system
to recover data from the data disk (destination folder is recovery-linux (for naming)). It successfully finished.
After a day I repeated that on my windows 10 To Go system on the same computer,
with the qphotorec version 7.2, which is my mistake, since by the changelog says the new version detects more filetypes (ig explaining the namings problem),
scanning that data disk, (destination folder here is recovery-win (for naming))
The scan on windows is now currently still running.

My questions are I suppose:
- If is it theoretically possible to get a different result, if I run the same qphotorec on windows and linux,
scanning the same not broken ntfs drive, basically I am asking if the operating system's DRIVERS are impacting the results)?
- If I am correctly resuming the process (with the filename index photores.ses editing?)
- (This is bonus, I can open a new thread, or just give me an actually useful link?) How to clone the disk using dd (not ddrescue - which is only for broken drives?)

Furthermore you did not indicate that you were taking any precautions to ensure complete shutdown.

Well the program is completely frozen and unresponsive for 4 hours you can't do much else. So I shut it down. But in theory if it starts again from the last file (OR SHOULD IT BE THE PRE-LAST FILE?) everything should continue as nothing happened? Again referring to my question above.

Furthermore, when dealing with a broken disk you risk yielding a diminished output on each additional run.
Better duplicate the drive using ddrescue as described in the manual.

The disk is not broken (it does not have bad sectors, can't be read...) so I hope that is OK then?

[recuperation]

You did not even bother stating the Windows operating used, naming the two versions of PhotoRec in question.
You are operating Photorec out of your disk containing a running operating system.

Okay sorry, I did not make myself clear. I hope this will be better: I have a laptop with two drives.

I guess you mean "disks" as partitions are sometimes referred to as "drives".

One is an active windows install as said with two main partitions (system and data (300 GB + 1700 GB = 2 TB)). The other drive is empty.
I wanted to install ubuntu on the empty drive, but I selected the wrong drive in the installer (Yes I am an idiot) so
I installed ubuntu on the active windows drive with my data.
but than as soon as I have realized what I did, I removed that ubuntu formated disk with data ("data disk" from now on) from my computer.
Then I installed fedora linux on my other (empty) drive, and a Windows To Go on a USB.
Only after that I placed my SSD disk in the primary SATA slot in my laptop.

I guess that is the broken one.

Then i first ran the latest stable version of qphotorec (7.1) on my fedora linux system
to recover data from the data disk (destination folder is recovery-linux (for naming)). It successfully finished.
After a day I repeated that on my windows 10 To Go system on the same computer,
with the qphotorec version 7.2, which is my mistake, since by the changelog says the new version detects more filetypes (ig explaining the namings problem),
scanning that data disk, (destination folder here is recovery-win (for naming))
The scan on windows is now currently still running.

My questions are I suppose:
- If is it theoretically possible to get a different result, if I run the same qphotorec on windows and linux,
scanning the same not broken ntfs drive, basically I am asking if the operating system's DRIVERS are impacting the results)?

No. You have been comparing apples and pies and you are wondering about the difference now. Photorec operates on sector level. Therefore it only needs the existing operating system calls for sectors when recovering. Your statement about NTFS-3G in your first posting does not play a role for the recovery process as NTFS-3G is a high level driver providing the functions of the NTFS file system.

- If I am correctly resuming the process (with the filename index photores.ses editing?)

If, then what? There is half of the sentence missing.

- (This is bonus, I can open a new thread, or just give me an actually useful link?) How to clone the disk using dd (not ddrescue - which is only for broken drives?)

No, ddrescue is not limited to operate on broken drives. It shows the progress in duplicating stuff, can be interrupted when using the logfile (now called "mapfile"). For both commands just use google - the operation of both commands are shown on lots of different sites.

Furthermore you did not indicate that you were taking any precautions to ensure complete shutdown.

Well the program is completely frozen and unresponsive for 4 hours you can't do much else.

Which program?! Photorec? If you mean Photorec, write Photorec, not "the program".

So I shut it down. But in theory if it starts again from the last file (OR SHOULD IT BE THE PRE-LAST FILE?) everything should continue as nothing happened? Again referring to my question above.

Furthermore, when dealing with a broken disk you risk yielding a diminished output on each additional run.
Better duplicate the drive using ddrescue as described in the manual.

The disk is not broken (it does not have bad sectors, can't be read...)

If there are no bad sectors it CAN be read (completely). I do not accept such statements unless proven.

so I hope that is OK then?

There is no reason to do the same job under two different operating systems. Instead of running "Windows on the go" just use a regular windows installation.

[kennysuper]

I worded it badly: the disk is NOT broken, i should have said the disk can be read normally and does not have bad sectors. Entschuldigung.

Now that the scan from the windows operating system is finished, the total data recovered (recovery-windows) folder is around 590 GB. The recovery-linux (same disk) is 95 GB. Why such a difference?

- Am I correctly resuming the process (with the filename index photores.ses editing?

This is just a question on its own, meaning if what i described doing to resume the operation is correct? or does this method of continuing leave any sectors out or something? Is this the correct way of continuing where you left of or is there a better method?

Sorry for my confusion and bad wording!

[recuperation]

Now that the scan from the windows operating system is finished, the total data recovered (recovery-windows) folder is around 590 GB. The recovery-linux (same disk) is 95 GB. Why such a difference?

I have to assume that there is a difference in program version (as I already guessed succesfully) and settings but as did not document how you came to result I can't help you.

Compare the results and check the files that are not contained in the smaller run with a size of 95 GB.
Maybe that helps you to find out what you did differently.

[kennysuper]

Is the method for resuming the operation correct, or is there a better way to continue searching from the last stop point?

[recuperation]

viewtopic.php?p=19421#p19421

[kennysuper]

Okay now I see that it is the version difference. If i ran the stable version again (7.1) it got the same results as on linux and
if i ran the new one (7.2-WIP) it got the same results as the windows scan and
vice versa, so the difference is only because of the different versions used and regardless of the OS - as you said and as it should be).

Thanks for telling me about cloning the disk with ddrescue. I suppose if I have a healthy disk,
there is no benefit running qphotorec from the disk itself, I can just run it from the disk image and it will get the same results (of course with a healthy disk).
Is this correct thinking?

And for continuing the search: the link you gave me talks about continuing the search from the known disk position x 128 (its position). My question is as in the forum thread i gave you, how to continue the search from the exact point where it stopped without the photorec.ses. As I understood the post says to look at the last file in the last folder that was created and inputing the filename number without the f at the front in the photorec.ses file as I said above:

Code: Select all

#1688699485
\\.\PhysicalDrive0 partition_gpt,255,blocksize,1024,fileopt,options,paranoid,keep_corrupted_file_no,wholespace,search,status=ext2_off,{FILENAME NUMBER OF LAST FILE WITHOUT THE "F" AT THE FRONT},inter
{FILENAME NUMBER OF LAST FILE WITHOUT THE "F" AT THE FRONT}-3907029167

is this line needed ({FILENAME OF LAST FILE EXCEPT THE "F" AT THE FRONT}-3907029167)? How do i know which is the last file recovered (from which file do i take this number). How exactly to get this number where to start from?

Also two suggestions (I dont know where are feature requests):
In the qphotorec add the option to continue last session as well (the cli has this option, the gui does not), since if it does not ask, the users don't even know that they can continue the last session.

Also maybe add this method of continuing an interrupted search without the original photorec.ses file in the FAQ or docs?

[recuperation]

Okay now I see that it is the version difference. If i ran the stable version again (7.1)

Use 7.2-WIP. It is not betaware and includes all intermediate improvements!

it got the same results as on linux and
if i ran the new one (7.2-WIP) it got the same results as the windows scan and
vice versa, so the difference is only because of the different versions used and regardless of the OS - as you said and as it should be).

Thanks for telling me about cloning the disk with ddrescue. I suppose if I have a healthy disk,

Supposing is not knowing.

there is no benefit running qphotorec from the disk itself, I can just run it from the disk image and it will get the same results (of course with a healthy disk).
Is this correct thinking?

I don't understand your reasoning at all.

And for continuing the search: the link you gave me talks about continuing the search from the known disk position x 128 (its position). My question is as in the forum thread i gave you, how to continue the search from the exact point where it stopped without the photorec.ses. As I understood the post says to look at the last file in the last folder that was created and inputing the filename number without the f at the front in the photorec.ses file as I said above:

Code: Select all

#1688699485
\\.\PhysicalDrive0 partition_gpt,255,blocksize,1024,fileopt,options,paranoid,keep_corrupted_file_no,wholespace,search,status=ext2_off,{FILENAME NUMBER OF LAST FILE WITHOUT THE "F" AT THE FRONT},inter
{FILENAME NUMBER OF LAST FILE WITHOUT THE "F" AT THE FRONT}-3907029167

is this line needed ({FILENAME OF LAST FILE EXCEPT THE "F" AT THE FRONT}-3907029167)? How do i know which is the last file recovered (from which file do i take this number). How exactly to get this number where to start from?

Please use the command line version and forget about modifying the ses-file if the linked thread does not help you.

Also two suggestions (I dont know where are feature requests):
In the qphotorec add the option to continue last session as well (the cli has this option, the gui does not), since if it does not ask, the users don't even know that they can continue the last session.

Due to the limited resources available I doubt this feature will be implemented soon.

Also maybe add this method of continuing an interrupted search without the original photorec.ses file in the FAQ or docs?

That does not make sense at all given the problems you have setting one parameter.