Linux recover deleted directory - linux

I had a directory named foo in my linux server. home/foo
I also had a file named foo.tgz in home directory.
I issued an extract of foo.tgz from home directory and the tar file had a directory named foo in it. So the directory home/foo got overwritten. Can I recover the old home/foo directory.

No, you cannot. It wasn't overwritten though, their contents were merged.

Related

Use of mv comand in Linux

I have a bunch of files
that have different extensions:
.png .fa .sh
which were in a directory called 'files'.
I wanted to move each
.png to images directory
.fa to fasta directory
.sh to upper directory Golden_Asian.git/
Moving the .png and .fa files worked well,
but for the .sh file, when I did
mv files/*.sh Golden_Asian.git
it just made type POSIX shell script, ASCII text executable, with the name
Golden_Asian.git
the name of the original file was
script.sh
so I was supposed to get a result like
Golden_Asian.git/script.sh
Did I do something wrong or is it the right result?
The original file in the "files" directory has disappeared, so I'm pretty sure
the file has been transferred to the right directory but don't understand why the name has been changed.
It's the right result if there was only one .sh file and there was no directory called Golden_Asian.git in the current directory. You executed mv files/script.sh Golden_Asian.git, so it moved the file from the original name to the name you specified. If there was already a file Golden_Asian.git in the current directory, it would be clobbered (replaced) by the new file. If there was a folder named Golden_Asian.git in the current directory, you'd have a file Golden_Asian.git/script.sh after the command. That's not what you got, so it is legitimate to deduce that you did not have a folder called Golden_Asian.git in the current directory when you executed the command.
If you'd specified:
mv *.sh Golden_Asian.git/
then it would have required the directory to exist and the result would have been a file Golden_Asian.git/script.sh. If you'd had more than one .sh file, then you'd have needed the directory Golden_Asian.git to exist. You said "upper directory"; did you intend to write:
mv *.sh ../Golden_Asian.git
If there was a directory in the parent directory called Golden_Asian.git, then the script would have been moved there. If there was no directory, the file would have been moved up a level and renamed. Again, a trailing / would have prevented confusion.
Note that moving a file into a GIT directory (especially a bare repository) is probably not a good idea.

will coping files recursively from one directory to another lead to changes in one directory reflect in another directory files also?

If I copy files from one directory to another directory:
Will their inode numbers also change?
Changes in file of one directory, will it reflect in same file of another directory also?
When I use command like:
cp -r dir1/ dir2/
With a simple copy the file system handle the copied files as newly created ones, therefore assining new inodes to them.
Any change made in the origin wouldn't change the copys. This only happens when you create symbolic or hard links between files.
You can check the inodes of your files with "ls -i filename".

Unix Permission: different chmod on folder and its files

Say a FOLDER is set to chmod 777 but FILES in the folder is set to chmod 755.
Non-owner user can write files to the FOLDER. Then how about overwriting the already existing files? Can the existing files be overwritten by a non-owner user?
If you give everyone read, write, and execute permissions on a directory, everyone can create and remove files, including ones that have been created by other users.
If you want to avoid such a behavior (one of your comments mentioned that), you should create another /tmp or /var/tmp directory: Set the sticky bit:
$ chmod +t directory
With the sticky bit set, every user can create new files, but is unable to remove files from others.
A fair word of warning here though: I do not recommend to secure your uploads with such a feature. Implement a better access control in your frontend instead.
Yes. While non-owners will not be able to open a file for editing and change its contents, they will be able to remove any file in the directory and replace it with a new file of the same name.

How does the 'mv' command work?

I used the command mv to move files from directory /a/b to directory /v/c. I wanted the whole 'b' directory to be moved to the path /v/c.
Now while running this command- mv /a/b /v/c I interrupted it in middle where the source had a large amount of data. Later I deleted directory 'c' since I thought it had partial files.
Now my question is will the directory 'b' contain all the original files along with the files that where moved to path /v/c? Or did I lose files by deleting the directory 'c'?
mv across filesystems will:
create the destination directory
for each file: copy and remove original
remove origin directory
Thus, if you interrupt it, some of the files will have been moved but not all. A mv of a directory within the same filesystem is atomic as it's just re-linking the directory's inode to a new location.
At one time, mv could only do the latter.
I believe it depends on if the source and destination directories were on the same file system or different file systems. If they were on the same file system then a "move" just changes the path information for each file. But if they're on different file systems the "move" command will copy one file at a time, and subsequently delete it on the source.
So, in your scenario if the source and destination were on separate file systems then yes, you just lost files if you interrupted mv and then deleted "c".

Not symlinking one or two files inside symlinked directory

Is there a way not to symlink one or two files within a symlinked directory in CentOS?
I've got the entire directory symlinked but there are two css files that I would like to use the current copy for the website
In short: no.
Another way to do this would be to symlink all the files in that directory, except those you want local copy of.
Still another way to go might be using unionfs or aufs to union-mount the original directory and a directory containing the files you need local, with the directory containing local files being "on top".
Say, your original directory is orig, the directory with files that should be local is local, the union directory is union, and you want files from both directories to be writable. Then you can union-mount them like this:
unionfs-fuse local=RW:orig=RW union
And unmount like this:
fusermount -u union
See unionfs manpage (unionfs-fuse(8) at least on Debian) for details.

Resources