Hello,

I actually used dd
Yeah, I killed my disk, I was tired, or I dont know the crap what I did that day.


After several times using Photorec, it is basic program that has no other better alternative. It can try to recover files. But one is limited by:
- one cannot select a new type of files, example avi extensino isnt in there even and one has a limited possibilities of files
- it is not recovering folders, because it doesnt care.
- it cannot create a new *.img (raw or gz) file of a crashed harddisk, *.img that is readable my mounting + loop
- one have to have a larger size harddisk to recover your data
- one has to seek the whole harddisk, and the user cannot have a list of files, and then give the possibility to recover (copy) only the one wanted to be recovered
- photorec does not recover the filenames even,


Or is there better program / code from Freebsd or MacOsX or windows (all platform) that we could compile? I mean that cannot be. In Windows there is so many apps and disk utilities.

something exactly like this for ext3:
http://www.softsia.com/screenshots/G...-NTFS_38vh.gif

Try to recover the partition with testdisk. If you fail at that, use foremost to recover the files. The file names cannot be preserved, and folders cannot be preserved ... these can only be preserved if you recover the partition.

If you wanna use Window$ go ahead, but you have to pay good money for all those apps and utilities and they're no better.

Hi,

first of all i will clamp, that you are very disrespectful to the programmer of photorec. Definitely this is the wrong way finding someone to help.

After that i ask me if you really understand how photorec works?
It searches a media for hex-strings identifying different file types and tries to determine what to recover and what not. At this time there are no folders and there is also no association between a file and a folder, so there is nothing not folder to recover.

Also photorec is not a software for drive or partition imaging. There is a large amount of other tools which will do this job very good.

I will stop here commenting your post, because i'm extremely displeased about you and your fashion how to talk about other programmers work.

Sorry. Well in NTFS or FAT32, one can use the getdataback and one can get back the folders and filenames, and almost all the data or almost the fully integrity of a whole disk. I am wondering why with EXT3 it is not similar, and is almost a all waste ... when crash occurs with ext3. Is EXT3 much worst than FAT/NTFS/Windows versus crashes: no filenames can be recover. Unfortuntaly testdisk did not recover the disk, no. So it is bad, and photorec is the only chance, but I am not willing to buy a 4GB because it is very expensive and Linux must have alternative to photorec (trying foremost).

Hi,

i see you edited your post and deleted some of your offends.

Best you take a look how photorec works on CGsecurity website, there is a brief description what it does, so you can understand why there is no possibility to recover file and folder names. If you don't know how the different file system types are handled you best take a look at wikipedia, there are very good articles on the different file systems.

So it is better to use the NTFS rather than EXT3. Then one can

I am not willing to buy a new harddisk because there is no tools to recover harddisk under linux.

foremost works only with an image.dd, also that is in raw and not gz or tar.gz tinier.

photorec does not recover folders and filenames + you need a similar size harddisk to recover your files. How do you do if you are poor or are a student? wasnt Linux made for students at the beginning or for studying Unix, too expensive at that time ?

So solution : use Windows, you pay but you do not loose you data.
You see that filenames are possible to be recover if one wants: http://www.fileguru.com/images/b/get...ools-65259.gif

http://images.snapfiles.com/screenfiles/getback.gif

Most of your -I might add 'wrong'- assumptions comes from the lack of understanding on how the recovering process takes place. Photorec can't recover files because it doesn't handle files. In first place, you completely overwrote the superblock, so you should be grateful for whatever photorec (or any other software) can find in your disk.

Photorec searches for patterns that resemble a given type of file, and saves whatever it can find. These data chunks might belong to a real file, to a deleted file or even be just random crap that out of pure chance look like a file of a given type, look at this:
http://www.cgsecurity.org/wiki/Photo...PhotoRec_works

There's no file name to recover. Even in the case of non-FAT based fs's, even if the name is still on some inode on the disk it's no longer associated to the data block. So I wonder how do you expect photorec to restore the name. The only possibility that I can think of would be to fish file names on the inodes and randomly associate them to the found data chunks, if you'd prefer that... Bear in mind that you are not undeleting files or something like that: you are trying to recover random data chunks from a completely broken "non-fs".

As said, it searches for patterns. The number of patterns it can recognize grows every day. And I have recovered video files from physically damaged disks using photorec, so I know from first hand that video files are in the category of patterns that photorec can handle. There are like five million (the exact number is not to be taken seriously) codecs and variants, I am sure you can understand that's impossible to support every one of them when there's not even a media player that can play everything either... Besides that, you know... it's open source and GPL'ed. If you don't like it improve it or pay someone else to do so.

Same above. To recover a folder you need it's name. Again, you are not undeleting, you are searching for patterns into a big massive data container with no fs on it. There's no pattern for directories, they are just files that contain files, usually.

Uh? What? Why should it? If you want to save your data into a loopback fs what's that's stopping you from doing so? Create your loopback fs, mount it, use it as a destination for the photorec output. Problem solved.

I have no idea what are you complaining about here. You need exactly the same amount of free space that the files you want to recover will take. If you are complaining because you can't save these files to the same device you are operating on then, please, stop and think again about it:

• If you write the recovered files into the same device then you will be overwriting the data you want to recover, and losing potentially valuable data in the process
• Besides you forget the fact that, in that device, at this point, has no valid fs, and hence you can't save files to it. To all effects, the device is unformatted.

Again, you ain't undeleting, there are no files. Forget about the files because they no longer exist as such. You are searching for byte patterns, and that's all you can do unless you find a way to fix the fs. Period.

Since there's no fs, you can't see "a list of files". You can only hope photorec finds something resembling a given file type, then read a sequence of bytes and save it to a file with an arbitrary new name.

There's testdisk. It can sometimes fix invalid fs's so you can mount them again and operate normally. Then you might be able to undelete files but that entirely depends on the fs and the tools that you have available for it. Failing that, all you can do is to search for patterns, might it be using some automation like photorec or a similar program, or manually using grep on the device file.

The whole key point is that no tool can find info that doesn't exist, and no tool can link unrelated chunks of information like a file name that's on a random inode and a byte sequence that's on the other end of the disk or four sectors ahead, it doesn't really matter. The capabilities of rescue tools on these situations are limited by the on-disk format, no amount of magic can bypass that.

You really don't understand the scope of what you did. Try overwritting a fat32 fs with an ext3 one and see what you can recover. In fat it would be equally bad, the fat table is at the beginning of the drive, with the same operation on fat you would not only have done the same damage, but in addition you would also have definitely erased all the file names physically from the disk, because they live in that fat table that you overwrote.

Linux was a project started by a man, now there are quite a lot of people involved, and each one has his own motivations. Besides that, no software can magically store info on thin air. I understand you are frustrated, but your are not reasoning right now.

There's a reason you can't overwrite a device node when you are a regular user. That means you probably used the root account to do the damage you did. Instead of taking the bad from the experience, learn that root privileges are not to be taken lightly like you do in some other OSes.

If you truly don't want to understand the difference between undeleting and a completely trashed volume I can't help you any more. Besides that, Windows is as good choice as any other. If that's your call, then that's what you should use and be happy with it. There's nothing wrong with that.

Hehehe, somehow I knew from the first post that this thread was going to turn out this way ... oh well.