Dear maintainer!
I have carefully read documentation https://www.cgsecurity.org/testdisk.pdf and issues related to original file names of restored files in current Github project (tried to search with https://github.com/cgsecurity/testdisk/issues?q=filename and https://github.com/cgsecurity/testdisk/issues?q=name). So I understand, that PhotoRec at current time is impossible to restore original file names because it does not use information from file system, that possibly preserve file names of deleted files. Also I understant, that TestDisk tool can restore deleted files with original names from some types of file systems including ext2, but ext3/ext4 are not supported, because "When a file is deleted from an ext3 and ext4 filesystem, the location of the first block is zeroed, so TestDisk can list all filenames, deleted or not, but it's not possible to undelete them." (#108 (comment)). But besides that I know that other attempts of tools creation that supports restoring files with original names from ext4 were in past. For example https://github.com/jboero/ExtundeleteX. Now this project looks abandoned and unusable (I checked it on recent Linux distros and did not succeed), but as I understood several years ago it worked successfully https://bugs.archlinux.org/task/56585. At least in some situations.
So, my question is - what do you think, is it possible to implement in PhotoRec new feature: attempt to match restored data with file names of deleted files in file system (if they still exists)? Maybe with more complex approach than used in TestDisk ("the location of the first block is zeroed"). After all, project https://github.com/jboero/ExtundeleteX mentioned earlier, was able to do this in some cases. Maybe it is possible to reuse it's logic and improve if needed? It would be a great idea, if it possible, do you agree?
P.S. The aim of this issue is not to request an implementation of described feature. The aim is to discuss possibility to implement it. Maybe I will try to do this later, becuse it sounds very interesting and challenging. But I don't want to waste time on obviously impossible feature. So I decided to pre-discuss this idea. I hope for your answer!
Dear maintainer!
I have carefully read documentation https://www.cgsecurity.org/testdisk.pdf and issues related to original file names of restored files in current Github project (tried to search with https://github.com/cgsecurity/testdisk/issues?q=filename and https://github.com/cgsecurity/testdisk/issues?q=name). So I understand, that PhotoRec at current time is impossible to restore original file names because it does not use information from file system, that possibly preserve file names of deleted files. Also I understant, that TestDisk tool can restore deleted files with original names from some types of file systems including ext2, but ext3/ext4 are not supported, because "When a file is deleted from an ext3 and ext4 filesystem, the location of the first block is zeroed, so TestDisk can list all filenames, deleted or not, but it's not possible to undelete them." (#108 (comment)). But besides that I know that other attempts of tools creation that supports restoring files with original names from ext4 were in past. For example https://github.com/jboero/ExtundeleteX. Now this project looks abandoned and unusable (I checked it on recent Linux distros and did not succeed), but as I understood several years ago it worked successfully https://bugs.archlinux.org/task/56585. At least in some situations.
So, my question is - what do you think, is it possible to implement in PhotoRec new feature: attempt to match restored data with file names of deleted files in file system (if they still exists)? Maybe with more complex approach than used in TestDisk ("the location of the first block is zeroed"). After all, project https://github.com/jboero/ExtundeleteX mentioned earlier, was able to do this in some cases. Maybe it is possible to reuse it's logic and improve if needed? It would be a great idea, if it possible, do you agree?
P.S. The aim of this issue is not to request an implementation of described feature. The aim is to discuss possibility to implement it. Maybe I will try to do this later, becuse it sounds very interesting and challenging. But I don't want to waste time on obviously impossible feature. So I decided to pre-discuss this idea. I hope for your answer!