Other grep to search for deleted files

vince66

vince66

Hello guys !


please, can you tell me if grep can be used with this sintax to search for deleted files:


Code: 
grep -b 'search-text' /dev/partition > file.txt


My apologize for the question ... I've only read the man page but I've did not try.


NOTE:

-b, --byte-offset Print the byte offset within the input file before each line of output.


Thanks in advance.
 
Hello Phishfry !

thanks very much.

Really I found the sintax of the grep command reading an article on the web without know if it can be used on FreeBSD .. and I've posted the question.

See you soon !!!

bye bye !!!
 
Well, yes and no.

With the above command, you are not searching the file system. You are searching the raw disk. This command will work on any Unix-style system (perhaps with some permission adjustment, you might have to be root). It will take a very long time; modern disks take about half a day to be read end-to end.

So the first question is: Will you find a deleted file on disk? That depends on two factors. A: Was the content of the file ever written to disk or not? It turns out that file systems don't have to write files to disk, unless the application uses some form of sync (like fsync() calls or opening the file in sync mode). Just writing to a file and closing it does not guarantee that a file is written to disk immediately; all Unixes have some form of write-behind. And in many (perhaps most) file systems, a file that is deleted before it is written to disk (meaning the only copy of the data is in memory at the time of the unlink() call) will actually never be written. Even worse: Some files are clearly temporary files (for example, if you creat() a file, then immediately unlink() it, but continue reading and writing it); there are file systems that have an optimization to suppress writing to temporary files unless absolutely necessary (due to memory pressure or fsync() calls), since the content of the file will never be read anyway if the system crashes. B: Is the content of the file still on disk? File systems overwrite disks all the time, as new content is written. If the file system was ever 100% full after the file was deleted, it is pretty much guaranteed that the old content is no longer on disk. But even if the file system was not completely full, it is quite possible that the space allocator in the file system code has decided to write where the deleted file has been written. Some file systems have a "lowest free address" allocator, which means that recently deleted files are very likely to be overwritten right away.

So not finding the string on disk has very little value; it proves nothing. Finding it on disk proves ... something, although not necessarily that the string was in a deleted file.

Next question: So you find the string on disk. What now? What have you learned? How will you use that knowledge? How can you find out which deleted file the string was part of?
 
Last edited:
Hello guys !
I'll take a look at you answer later .. now i'm busy ... thanks in advance for your kindly reply.

:):):):)
 
ralphbsz said:
Well, yes and no.

With the above command, you are not searching the file system. You are searching the raw disk. This command will work on any Unix-style system (perhaps with some permission adjustment, you might have to be root). It will take a very long time; modern disks take about half a day to be read end-to end.

So the first question is: Will you find a deleted file on disk? That depends on two factors. A: Was the content of the file ever written to disk or not? It turns out that file systems don't have to write files to disk, unless the application uses some form of sync (like rsync() calls or opening the file in sync mode). Just writing to a file and closing it does not guarantee that a file is written to disk immediately; all Unixes have some form of write-behind. And in many (perhaps most) file systems, a file that is deleted before it is written to disk (meaning the only copy of the data is in memory at the time of the unlink() call) will actually never be written. Even worse: Some files are clearly temporary files (for example, if you creat() a file, then immediately unlink() it, but continue reading and writing it); there are file systems that have an optimization to suppress writing to temporary files unless absolutely necessary (due to memory pressure or fsync() calls), since the content of the file will never be read anyway if the system crashes. B: Is the content of the file still on disk? File systems overwrite disks all the time, as new content is written. If the file system was ever 100% full after the file was deleted, it is pretty much guaranteed that the old content is no longer on disk. But even if the file system was not completely full, it is quite possible that the space allocator in the file system code has decided to write where the deleted file has been written. Some file systems have a "lowest free address" allocator, which means that recently deleted files are very likely to be overwritten right away.

So not finding the string on disk has very little value; it proves nothing. Finding it on disk proves ... something, although not necessarily that the string was in a deleted file.

Next question: So you find the string on disk. What now? What have you learned? How will you use that knowledge? How can you find out which deleted file the string was part of?
Click to expand...

I have been taken the time to learn about hard drives recently and I can tell that this post, as well as the other one you made in TS's thread about how to show dd output, while running, is very helpful. I'll save these two posts into a document.

Edit: Woops. This post would have been better placed in the other thread made by TS but the point is still the same. :)
 
You must log in or register to reply here.
Back
Top