I just renamed a log file to "foo.log.old", and assumed that the application will start writing a new logfile at "foo.log". I was surprised to discover that it tracked the logfile to its new name, and kept appending lines to "foo.log.old".

In Windows, I'm not familiar with this kind of behavior - I don't know if it's even possible to implement it. How exactly is this behavior implemented in linux? Where can I learn more about it?

  • I'm not putting this as an answer because I don't really know but I think it has to do with inodes not being changed when you move a file. – mathepic Feb 20 '11 at 13:25

Programs connect to files through a number maintained by the filesystem (called an inode on traditional unix filesystems), to which the name is just a reference (and possibly not a unique reference at that).

So several things to be aware of:

  1. Moving a file using mv does not change that underling number unless you move it across filesystems (which is equivalent to using cp then rm on the original).
  2. Because more than one name can connect to a single file (i.e. we have hard links), the data in "deleted" files doesn't go away until all references to the underling file go away.
  3. Perhaps most important: when a program opens a file it makes a reference to it that is (for the purposes of when the data will be deleted) equivalent to a having a file name connected to it.

This gives rise to several behaviors like:

  • A program can open a file for reading, but not actually read it until after the user as rmed it at the command line, and the program will still have access to the data.
  • The one you encountered: mving a file does not disconnect the relationship between the file and any programs that have it open (unless you move across filesystem boundaries, in which case the program still have a version of the original to work on).
  • If a program has opened a file for writing, and the user rms it's last filename at the command line, the program can keep right on putting stuff into the file, but as soon as it closes there will be no more reference to that data and it will go away.
  • Two programs that communicate through one or more files can obtain a crude, partial security by removing the file(s) after they are finished opening. (This is not actual security mind, it just transforms a gaping hole into a race condition.)
  • 1
    I agree with @dmckee, I just wanted to note: a program can open a file for reading and writing (as what has happened with the log file in the question). – jsbillings Feb 20 '11 at 15:16
  • @jsbillings: Yes, but there is a risk. If all the filesystem names are gone, you can write GBs to a open file which will evaporate like the morning dew as soon as you close it. – dmckee --- ex-moderator kitten Feb 20 '11 at 15:21
  • 1
    Also, the inode is copied into the kernel and that is what is operated on, not the disk copy. So the file could be mv'd or cp', but an open file is already working with the kernal data stuctures, not the disk version. So if you copy another file into the file that is open for writing, the process will still write to the same relative position as in the old file. This is the reason why programs, like Apache httpd, have a signal handler which closes and reopens the log files. – Arcege Feb 20 '11 at 15:36

To really see how this behavior is implemented you could look at some Unix programming books. Mathepic is right in that it is related to an inode. The actual pathname is only used to open the file, once that's done the program references it by its opened file descriptor. The file descriptor in turn references the inode, which in this case doesn't care if the underlying files name has changed.

As far as implementing this in Windows, that's a question for another site.

To read more about this without hitting the books just search around for linux filesystems and inodes. There might not be a clear answer, but you'll be able to understand why.

  • 4
    "Search around -- you'll probably not find a good answer but will understand it" isn't a good answer. – mattdm Feb 20 '11 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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