Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Being a super user , I executed the following command on linux
rm rm
which removes itself. Because when process is in execution , its reference count
is not zero.Hence it cannot be deleted. So I am bemused,
how and why does it happen?
I tried the same with chown 0000 chown as well.
cp -r Dir1/ Dir2/
In above command also , what happens when i delete the source directory only when copying is in progress???
It is the same as for temporary files.
Recall that a usual way to create some temporary file is to open(2) a file (keeping its file descriptor), then unlink(2) (while still having an open file descriptor). Then the data of the file remains in the file system as long as the process is running and have not close(2)-d that file descriptor.
This is because files really are inodes -not file names in directories. (directories contain entries associating names to inodes).
The kernel manages the set of "used" (or "opened") inodes, and that set contains the inodes executed by processes (actually, the inodes involved in some address mapping like thru mmap(2) or execve(2))
So just after /bin/rm /bin/rm starts, the kernel has one reference to rm binary as the executable of the process.
When it processes the unlink syscall, it has temporarily two references (one being the process in execution, the other the path /bin/rm passed to unlink kernel implementation) and decreases it to one.
Of course you should avoid typing /bin/rm /bin/rm but then you usually have some standalone shell like sash to be able to repair your system.
On Windows, "rm rm" is probably not possible, because of the reference count you mentioned. On most *nix systems however, it is. "rm" and also "chmod" is loaded into memory and only then will execute whatever the commandline specified. Another example: edit a file in one window and while editing that file, remove it in another window. That too should be possible on most *nix systems, regardless of reference counts.
You cant delete a directory using rm until its empty..
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
Improve this question
I'm having trouble finding them, and how to use them in general. for example i see in x86 functions, the output may be a file descriptor. i cant seem to find much about them on the web so im trying it here. and yes im very new to linux
The list of file descriptors is:
ls -l /proc/self/fd
Every process has its own list.
The following script will print all file descriptors of all processes.
#! /bin/bash
find /proc -maxdepth 1 -type d -regex '/proc/[0-9]+' -printf '%P\n' |
{
while read -r pid; do
if [[ -d /proc/$pid ]]; then
printf '%d:' "$pid"
find /proc/"$pid"/fd -type l -printf ' %P' 2>/dev/null
printf '\n'
fi
done
}
You need root permissions to execute it.
A file descriptor is basically just an integer. It gets returned by certain functions, e.g. open().
It is used very similar to a pointer in C, you don't do much with it except pass it to other functions, e.g. read(). I don't think doing pointer arithmetic on file handles makes that much sense, though. The fstat() system call will return you a bunch of information about the file. See the manpage:
man 2 fstat
Each process has its own list of file handles, the numbering always starts at 0 for STDIN, 1 for STDOUT and 2 for STDERR, then continues simply counting up as you open and close files.
Except for the first three, that number has no deeper meaning, it just tells the kernel which one from its list of open files it should operate on. The concept seems to be so simple that nobody has bothered to document it... ;-)
Is there a list of linux file descriptors somewhere?
Yes, the kernel maintains a list of open file descriptors per process. This is the reason you don't find it in internet (it is very dynamic). The ones a process always receives already open, when the program starts are: 0 (standard input); 1 (standard output); and 2 (standard error). This is the mechanism employed in unix systems to allow the parent process to redirect standard input, standard output or standard error. Other file descriptor numbers are assigned/created by the kernel when you open() a file, create a socket with socket() system call, pipe() system call, or some other way (there are many)
A file descriptor per se is just a unique number (each process has a set of distinct numbers) the kernel uses to convey with the process a reference to a kernel resource (like a name) that the program is going to use. When you open() a file, you provide a name and the way you are going to access it (read only, read/write, write only or none -- this last to deal with resources that don't allow you to read/write them, like directories or the like) and receive in exchange a descriptor number that will be used in all the calls related to that file/socket/etc.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I hope this is the right place to ask this question.
While trying to move a big directory "mydirname" (abt900GB), in a remote linux server, from /abc/source to /xyz/target ; I used the following command in sourcedirectory,
mv mydirname /xyz/target/ &
However, after a while the process got interrupted and gave an error,
mv: cannot stat `mydirname/GS9/set04/trans/run.3/acc': Stale file handle
mv: cannot stat `mydirname/GS9/set04/trans/run.4/amc': Stale file handle
.
.
.
and many more such messages mentioning different subdirectories locations.
The problem is that, the process has moved about 300gb of data. However, there are many directories which are not fully moved. Similar, problem occurred with another transfer (about 500 GB) that was running at the same machine.
Also, I am no longer in the same working session. I have disconnected and reconnected to the remote server.
It would be great if you help with following queries.
Is it possible that some of the file are not fully-transferred (i have seen such cases in 'cp' command where if a process interrupts, it results in lesser size file at the destination.
How can I resume the process so that I do not loose any data. Will 'mv' command be enough? or is there any special command that can work in background.
Else, is there a command to undo the process and restore the 'mydirname' to original location 'source'.
Use "rsync" to complete a job like this:
rsync -av --delete mydirname/ /xyz/target
It will verify that all files are moved, of the proper length, correct timestamps and will delete any leftover garbage.
You can test first with a "dry run" to see what the damages are:
rsync -avn --delete mydirname/ /xyz/target
This goes through the whole rsync process but doesn't actually do anything. It's usually a good idea to run this test to check your command syntax and see if it's going to do what you think it should do.
The "rsync" command is actually more like a copy "cp" than a move "mv". It will leave the source files in place and you can delete them later when you are satisfied that everthing has transferred correctly.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm using Ubuntu 14.04 and I made an empty directory on /tmp with the mkdir command:
cd /tmp
mkdir foo
and then I checked it's size using ls:
ls -ldh foo
and the result shows that the size of the directory is 4KB, although it has nothing inside!
then I created an empty file with touch:
touch empty
and then I checked its size:
ls -l empty
the result shows that the empty file is of 0B, which differs from the empty directory.
I've read about some Q&A's saying that the 4KB is the metadata of the directory. But if it is the metadata, what kind of information is stored inside and why it is so huge, and why an empty file don't have such kind of metadata? If it is not the metadata, what does the 4KB mean?
I'm going to break this question down into 3 parts, 2 of which I can answer...
Part 1: why isn't an empty directory size 0?
Because it contains . and .. so it's not really empty.
Part 2: Why is 4K the minimum?
Because that's the filesystem's block size. You can set it smaller when you create the filesystem, but there is overhead. The filesystem must remember a free-or-in-use flag for every block, so smaller blocks = more blocks = more overhead. (In the early days of ext2, the default block size was 1K. Disks were small enough that the space saved by not allocating a multiple of 4K for every file was more important than the space used for the free block map.)
Block sizes over 4K aren't possible because 4K is the page size (the smallest unit of virtual memory) on most processors, and Linux wasn't designed to deal with filesystem blocks bigger than memory pages.
Part 3: When you ls -l a regular file, you get the actual number of bytes used but when you ls -ld a directory, you get the number of bytes allocated. Why?
This part I don't know. For regular files, there is an allocation size you can view with ls -s, and the two sizes actually tell you different things. But on directories, the -l size is like a redundant copy of the -s size. Presumably the kernel could report a size that indicates how much of the 4K block is actually used, but it doesn't. I don't know why.
The metadata a directory contains is a series of directory entries. It's not empty upon creation because two dirents are immediately created: one for that directory, called ".", and one for its parent directory, called "..".
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In the /proc file system, why is that some files have their maps file empty. Is it because no memory has been allocated to them or the data isn't available?
They must be allocated some memory, otherwise how are they running?
First, notice that all the pseudo-files /proc/1234/maps and /proc/self/maps have always a zero size, as reported by the stat(2) syscall and the ls command. However, they are sequentially readable (e.g. by the cat command, or with read(2) syscall, e.g. called by fgets). Try cat /proc/self/maps and ls -ls /proc/self/maps for example.
A probable reason for the /proc/*/maps files to have a 0 size is that computing their size means computing their content, and that could be expensive. So the kernel prefers to say 0 for their size. Think of them as being sort of pipes. You need to read them sequentially, they are not lseek(2)-able.
Read the proc(5) man page for details about /proc/; notice that it is using Unix permissions and ownership, so you cannot access a /proc/1234 directory if the process of pid 1234 is not yours.
And you might also have some zombie processes. These don't have any address space anymore, so I won't be surprised if their maps pseudo-file in /proc is truly empty (in the sense that reading it gives immediately an end-of-file condition), or even missing.
Remember that files under /proc are pseudo-files, in the sense that the kernel is providing them (and giving their data), and they don't involve any real disk I/O. In particular, reading them should be fast.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have read about limiting size of directory - like creating big files, formatting,mount,.. etc.
But this all very complicated. Does exist utility or something else to set limit on already existing directory?
Quota is based upon filesystems, but you can always create a virtual filesystem and mount it on a specific (empty) directory with the usrquota and/or grpquota flags.
In steps this will be:
create the mount point
create a file full of /dev/zero, large enough to the maximum size you want to reserve for the virtual filesystem
format this file with an ext3 filesystem (you can format a disk space even if it is not a block device, but double check the syntax of every - dangerous - formatting command)
mount the newly formatted disk space in the directory you've created as mount point, e.g.
Code:
mount -o loop,rw,usrquota,grpquota /path/to/the/formatted/disk/space /path/of/mount/point
Set proper permissions
Set quotas
and the trick is done.
Tutorial here.
Original answer here
You could limit the quota on a filesystem. But it is not directory specific, but file system & user specific.
You might also consider developping your own user space file system using FUSE, but this will take your time.