Talk:PhotoRec
 | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
 | The following Wikipedia contributor may be personally or professionally connected to the subject of this article. Relevant policies and guidelines may include conflict of interest, autobiography, and neutral point of view. |
PhotoRec / TestDisk, and Conflict of Interest label edit
As explained here, I think that both PhotoRec and TestDisk do not deserve Conflict of Interest labels. LittleBen (talk) 13:56, 17 July 2012 (UTC)
Incorrect information about ext2/ext3/ext4 edit
In general, most operating systems try to store the data in a contiguous way so as to minimize data fragmentation.
Ext2/3/4 like other traditional Unix filesystems stores files fragmented on purpose to maximize disk throughput and make defragmentation unnecessary. Is not even possible to store a file bigger than 8 Megabytes contiguously on a Ext2/3/4, because of the maximum blockgroup size. So in general on Ext2/3/4 file data is always interleaved with metadata (Inodes) and not stored continuously. Due to this fact, the File carving technique doesn't work well.
To gather the fragments, PhotoRec would have to read intact superblock backups or still intact Inodes. But it doesn't do that, so it is almost useless for Unix/Linux filesystems. You may get back some small files (few kilobytes) by chance, but for a comprehensive recovery you need a tool, which understands damaged ext2/3/4 filesystems.
While FAT12/FAT16/FAT32/NTFS lose all data with their allocation tables (FAT/MFT) damaged (and need PhotoRec then), there is always intact scattered metadata (Inodes) even on heavily damaged Unix/Linux filesystems. For good results, you need recovery software, which understands it and is able to successfully reassemble the file fragments.
--92.224.117.136 (talk) 08:26, 11 April 2014 (UTC)
- But if they say it supports ext you would think it 'really' does support it, and not just claim it for whatever reason. Maybe they do analyze the filesystems correctly? --84.48.98.158 (talk) 18:29, 16 October 2014 (UTC)