Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 1 down vote favorite

It is well known that UNIX systems won't actually delete a file on disk while the file is in use. So if a file is being accessed by process 1 and process 2 deletes the file using rm, process 1 continues to see the file; additionally the file descriptor link at /proc/(process 1 id)/fd reports the original contents of the deleted file.

However, if process 2 overwrites the file as opposed to deleting it (say with echo "abracadabra" > file.txt), the file descriptor link at /proc/(process 1 id)/fd reports the overwriting material("abracadabra"), while process 1 is still able to access the original contents of the file. Why this difference?

[Edit]The snippet below is in response to Jim Paris

>uname -a
Linux ravoori-netbook 3.2.0-32-generic-pae #51-Ubuntu SMP Wed Sep 26 21:54:23 UT
C 2012 i686 i686 i386 GNU/Linux
>echo original > /tmp/foo
>tail -0f /tmp/foo &
[2] 6144
>rm /tmp/foo
>cat /proc/6144/fd/3
original
>echo abracadabra > /tmp/foo
>cat /proc/6144/fd/3
original
share|improve this question
Each directory entry is a hard link to the file. A single file can have entries in multiple directories (i.e. multiple hard links). The kernel will reclaim the disk blocks once the last link to the file is gone. Until then, unlinking merely removes the directory entry - it does nothing to the file contents. – jw013 Oct 17 '12 at 20:14
@jw013, thanks. With respect to the overwrite scenario described above, understood that the reading process continues to see the original file contents but why does the descriptor under /proc/<<process ID>>/fd point to the new contents? This is different than the delete scenario where /proc/<<process ID>>/fd clearly points to original file – Chandra Ravoori Oct 17 '12 at 21:10
Process 1 obtains fd to a file. Process 2 obtains fd to the same file. Both processes see the same contents. This is natural and expected behavior. Whatever one process writes the other can see because both have the same file open. – jw013 Oct 17 '12 at 22:27

2 Answers

up vote 2 down vote accepted

If process 1 has already started reading the file before process 2 overwrites it, then it will have some part of the contents stored in the stdio buffer. Once it crosses the buffer-size boundary it will be forced to go to the kernel, and then it will find the new overwritten contents.

share|improve this answer
up vote 2 down vote

However, if process 2 overwrites the file as opposed to deleting it (say with echo "abracadabra" > file.txt), the file descriptor link at /proc/(process 1 id)/fd reports the overwriting material("abracadabra"), while process 1 is still able to access the original contents original le.

I disagree:

$ echo original > /tmp/foo
$ tail -0f /tmp/foo &
[1] 20591
$ rm /tmp/foo
$ cat /proc/20591/fd/3
original
$ echo abracadabra > /tmp/foo
$ cat /proc/20591/fd/3
original

The fd link still shows the original contents, contrary to what you claimed. This is with Linux 3.5. Are you seeing something different?

share|improve this answer
I see different behaviour. Please refer snippet added to original question. – Chandra Ravoori Oct 18 '12 at 1:04
Actually, your snippet above appears to prove my point. The abracadabra displayed by the final cat is different than the original content. However, this same procedure when run on my setup provides results that are contrary to my original point. The original question pertained to a production situation involving processes under different sessions slowly looping through large files therefore the stdio buffering referenced by aecolley might have something to do with it. – Chandra Ravoori Oct 18 '12 at 1:21
Oops, you're right, I hand edited that transcript and messed up the most important part! I ran the commands again and they match your output; I'll fix the snippet. – Jim Paris Oct 18 '12 at 6:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.