I'm not sure I understand a) what the point of this restriction is, or b) what it even means. Testdisk/photorec do not need to be downloaded from a random website, that's rarely how software is installed in Linux. They are included in the standard repository or extended repositories for almost all distros.

So what does "came with the distro" even mean? If it's available on the installation DVD but wasn't installed by default because of the installation type chosen by the user, did it "come with the distro" or didn't it? What if it's on the installation DVD but not the CD? Or what if the user did a net install? Or what if it's in the distro's standard repo but wasn't included on the DVD because of size restrictions?

If you simply mean that no tools can be installed on the machine that weren't already installed when the exercise began, then that simply means your success/failure in this project depends entirely on the type of installation the original user performed, which is a really stupid restriction. Also, what about booting a live distro and doing the recovery from there? testdisk/photorec come standard on all of the recovery distros.

I agree with rknichols - this exercise is so far removed from real life that it's pointless. I have done exactly what this exercise targets. I copied over some images from an SD card to my computer, deleted them off of the SD card, and then due to a small fubar in a processing script I accidentally deleted all of them off of the computer. I then used dd to create a backup image of the SD card, and ran photorec on that backup image, which recovered all of the images flawlessly.

If some of you use an internal SSD drive with TRIM enabled, recovering files is NOT possible. You CAN however recover files from USB drives and external SSD drives.

http://www.howtogeek.com/187104/warn...external-ssds/

I went hunting for the trash folder but no luck. As root I ran, "find / -name T*" and no file name trash was listed. I looked at system info and found the following information:

Operating System: Slitaz GNU/Linux 3.0
Desktop Environment: Unknown (Windows Manager: Openbox)

as was posted above
if only RAM is used
there is really nothing to recover at lease easily without a full forensic lab

The root filesystem for SliTaz is a tmpfs in RAM. Unless that user's image folder is located somewhere else on a conventional filesystem, there is nothing to recover.

Somehow I feel the point of this "assignment" is just to encourage some downloads of SliTaz.

But if files are deleted from the GUI, R-click on file, the distribution is configured to put those files somewhere. Where can I look to find out where those files are?

You can run this command to search for a trash directory and list the contents there in. The wildcards are used in case there are prefixes and suffixes in the directory name. The -iname will match both upper and lower case patterns.


But as rknichols mentioned, if the whole filesystem was using tmpfs. All files are gone when you turn off the computer.

You can always create a file, delete it from the GUI, then run "find $HOME -cmin -2" to find everything under your home directory that has been changed, renamed, or moved within the last 2 minutes. Then, look for the corresponding location in the other user's account. I do that sort of thing all the time to see where some GUI config tool stores stuff.

But if it were that simple, that user could have recovered the files from his/her trash. I suppose you could see whether your CLI "rm" command is aliased to something that saves deleted files ("type rm" or "type -path rm"), but that isn't standard in SliTaz.

[EDIT] Arrgh! The crippled find command in SliTaz doesn't have "-cmin". Here, the trash bin is in ~/.local/share/Trash/files/ . But as I indicated above, this would have to be a user that lacks the ability to click on the "Trash" icon on the desktop to recover deleted files.

This did not return anything.

Hence my problem...

Presumably the boot process for this VM sets up the filesystem as though those image files had been created and deleted. If they were deleted via a GUI file manager, then there would be some sort of trash folder. If they were actually unlinked (via rm), then the tmpfs would no longer have any record of their content. Those data blocks would have been released back to the kernel's free memory pool and no longer recoverable except by extraordinary means (freezing the VM and using forensic tools on the host to examine its memory -- that sort of thing).

Last ditch would be to run a "find . -type f" in that user's home directory and see of anything that looks like image files shows up. Frankly, I doubt that will discover anything.

As a final attempt to see what is going on, what is the output from "cat /proc/mounts"?

In the OP's first post his filesystem is so:

The / filesystem which includes the home directory is running in ram via tmpfs. So, theoretically, anything the OP did within slitaz is erase when the machine has turn off.

I have an SSD drive and to limit the writes to extend the life of my drive, I have /tmp and /var/log running in a tmpfs filesystem.

When I turn off the computer, all files in /tmp and /var/log are gone. And newer files with the current date are created when the system reboots.

Another idea the OP could have done beforehand is used a sticky bit for the Image directory. If users were given permissions to write to this directory, the sticky bit can prevent other users except root from deleting other user's files. However, sticky bit isn't useful on a tmpfs filesystem unless you keep the machine on 24/7.

I downloaded siltaz 5.0rc3 and ran it in a VM to prove my assumption that a tmpfs filesystem does not keep the created files and directories once the system or VM is shutoff.

Upon booting, siltaz 5.0 has a trash folder on the desktop. From the GUI file manager, I created some files and deleted them by right-clicking on the files. A dialogue opened up and I selected Move to Trash. Upon doing this, the deleted files were in the trash folder.

The second test was to reboot the VM and to see if the deleted files and the Trash directory will be retained.

When the system was up and running again the deleted files in the Trash folder were gone as well as the ./.local/share/Trash directory.

Below are two images of the siltaz desktop. The first one shows the trash folder icon with files in it. I also ran three commands df , uname , and find to show the existence of a Trash directory in the user's home folder.

The second image shows the siltaz filesystem after the reboot. The deleted files are gone from the trash icon as well as the ./local/share/Trash directory.

As you can see, a filesystem using tmpfs is not permanent. Anything you do or create is gone on the next reboot. If you or the other party had installed siltaz on a virtual disk in a VM, this may have been a different story and possibly be able to recover the files.

I'm afraid if you did ran siltaz with a tmpfs filesystem and created some files and then rebooted. Those files are gone.

Attached Thumbnails

   

does this work the same to Android phone? I need to recover a few photos on my Galaxy S6

With a simple google search there are ways to do so. You'll need to read each link and see which is more doable for you. Some links will use windows based tools or linux based tools. Also, some instructions will be specific to internal, external or both.