I did something like:
$ cd /A/B/ $ rm -rf ./* $ rm -rf ../**
Due to network issues my system disconnected from Ubuntu. When I came back there were no files or folders in the
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.Sign up to join this community
rm removes files. It does not put them in Trash so they cannot be restored by normal methods.
-rf tag does two things:
-r tag stands for
recursive which means that it deletes the path or file you specify AND everything else below it.
-f tag stands for
force, which means that the operation will complete without any further prompts.
To answer your question about syntax, remember that
./ is the path of the current directory and
../ is the path of the "parent" directory (the path above the current directory).
So if you run
rm -rf ../* while under
/A/B/, then you are deleting everything under
If you're going to use
rm -rf, be aware that this is a very powerful command that will indiscriminately and permanently delete everything in the path you specify.
Your only option to recover files from this operation are advanced data recovery tools like photorec/testdisk. These applications are not always successful in restoring data, and any further use of your device decreases the likelihood that they will recover anything.
The best path is to restore from backups.
When you run
rm -rf ../** in directory
/A/B, it goes back to directory
/A and removes everything in there, since
.. is the parent directory.
If you want to be able to "restore" data, you should consider running a filesystem with active snapshots enabled.
BTRFS have snapshots implemented, and auto snapshots can be configured.
If you for instance have configured hourly snapshots for the last 24 hours, and daily snapshots for the last 14 days, you could roll back to any of those snapshots for a given filesystem at any time.
The exact configuration of automatic snapshots will vary with the chosen filesystem.
The reason this "just works" is that both filesystems implement "copy-on-write", where every change to the filesystem is written to a new location - so no data is removed until the snapshots and the pointers to the old data expire.
What you actually did is that (../**).
as you can see you put the double dot in the given command which deletes everything that comes before your working DIR.
Now let's see how it work. Just imagine we have a location directory with the name XYZ,
# pwd / # mkdir XYZ # cd XYZ # pwd /XYZ
As per the above command, I created a directory. which can be considered as -> /A/B
now when you run the below-mentioned command it will only delete everything within the working directory which is /XYZ
rm -rf ./**
But when you run the same command with a double dot icon the command itself will change its location of the running directory and delete everything which comes before /XYZ from there only but since the user working in a folder that exists in that directory which is getting delete at that time only that folder will be left undelete and everything will get deleted.
It's quite hard to tell whether you can recover your data or not but you can use photorec which helps you to recover your data but it will change the recover files name randomly so if you know what was there you can else I don't think so you can recover your data .
hope this answer your question.
Your are recursively deleting files and folders from a folder. In one case the parent folder.
It would help a little if you told us where you were but if this is sensitive then you are likely somewhere under /home or /opt or /var as other places have boilerplate names you should not be afraid of sharing.
You can restore the files from an external source, but if you deleted bin folders there may be issues with your system stability.
You can mount the disk to another machine for restoration in this case.
I would expect you to have backups of the major trees. In the cloud (and even locally) you can fall back to a recent whole of disk image and just restore /home, /var, and anything that you have backed up as being relatively volatile.
NB. - restoring the tree with cp or rsync can be a de facto defrag.