Change recovered filename to handle more than 2^32 sectors.

[willgetheresomeday]

Dealing with a large drive I noticed the sector number drop in the recovered filename. Checking with hdparm the data at the sector didn't match but earlier files did. but adding a multiple of 2^32 located the sector.

Looking (quickly) at the code it uses 'unsigned long' for the file locations but then casts to 'unsigned int' when creating the filename.

[cgsecurity]

Which version are using ? (output of "photorec -version") Are you using a 32-bit version of PhotoRec ?

[willgetheresomeday]

testdisk-7.0-11.fc27.x86_64

[willgetheresomeday]

PhotoRec 7.0, Data Recovery Utility, April 2015 Christophe GRENIER grenier@cgsecurity.org http://www.cgsecurity.org

Version: 7.0 Compiler: GCC 7.1 Compilation date: 2017-08-05T00:23:11 ext2fs lib: 1.43.5, ntfs lib: libntfs-3g, ewf lib: 20140608, libjpeg: libjpeg-turbo-1.5.1, curses lib: ncurses 6.0 OS: Linux, kernel 4.13.9-300.fc27.x86_64 (#1 SMP Mon Oct 23 13:41:58 UTC 2017) x86_64

[cgsecurity]

You can try the fixed version using

dnf copr enable grenier/testdisk
dnf update testdisk

Please tell me if it works as expected.

[willgetheresomeday]

Thanks for the update will report back next week.

[willgetheresomeday]

That didn't work.

Recovery got as high as 4290195791 and the next file was at saved as 26021629.

So some mod 2^32 still being done.

But I've just noticed ....photorec -v says

PhotoRec 7.1-WIP, Data Recovery Utility, November 2017

not

PhotoRec 7.1-WIP, Data Recovery Utility, April 2018

[cgsecurity]

Can you check that copr is enabled and the version after a "dnf reinstall testdisk" ?

[willgetheresomeday]

copr was enabled.

'install' from 'grenier-testdisk' gives 'November 2017' 'reinstall' from 'grenier-testdisk' gives 'April 2018'

Will test the fix and report back.

[willgetheresomeday]

Fixed.