I'm seeing two separate cases where there's a (random?) delay before a new or modified file appears.

The first case is my Rails development environment: I modify a code file (in vim) and save it, switch to my web browser and reload the page. The Rails server notices that something has changed and reloads. All is fine and well, except sometimes the modified file disappears for a few seconds and Rails complains about a missing file.

The second case is the Sphinx indexer in our production environment. I have a delta indexing setup - the Sphinx indexer creates new index files and merges them into the existing ones. All is fine and well, except every now and then (about once every 10 minutes) one of the new files does not exist when the indexer tries to read it - the same process that has just written it and knows for a fact that it is there.

In both cases, the file is there a few seconds later, looking smug as if nothing happened.

Can anybody explain these, or give some clues on where to look for a solution?

The development environment is running CentOS 6.3, and the filesystem I'm working on is a local ext3. The production environment is a Debian 7 (wheezy), and the Sphinx index files are on a local ext4.


This is a problem caused by Vim. Vim deletes the files before writing out the new file. This is contrast to e.g. Emacs (and the WingIDE editor) I use.

I have noticed this with a small python utility I run when testing new code: it cycles to see if any of a list of files has changed based on their timestamps and then executes some command (usually .py files are checked and the first of these is used as an argument to python for a test run).

There is no problem ever when using emacs or wingide, but when I happen to use vim to change one of the files under observation, the python utility exits because the files which' timestamp it tries to check does not exist.

  • 2
    That's not true; vim takes great pains to preserve the original file. Try hardlinking a file and check with ls -li that the file is indeed linked (has a link count of 2) and make a note of its inode number. Now edit the file with vim, and save it. Now do ls -li again; the file is still hardlinked and still has the same inode number. Anyway, even if the file was deleted and recreated, the time window in which the file doesn't exist is very small and not long enough to explain why after editing the file loading in the browser fails (for which I have no expl. besides maybe caching probs – wurtel Dec 11 '14 at 13:13
  • @wurtel I only ever have this problem while working on one of the 'observed' files with vi, so that is why I point the finger there as nothing else is changing the files. Maybe it is something in my configuration. – Anthon Dec 11 '14 at 13:36
  • Note that vi is not always equal to vim... vi did in fact remove the file first. Also if you don't have write permission to the file and don't own it, but you are allowed to remove it, then you can use :w! to force vim to remove the file and recreate it under your user ID. – wurtel Dec 11 '14 at 15:29

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.