I'm new to this forum and hope I'm not missing basic etiquette rules here. There is a discussion going on in the UNIX and Linux Forums "UNIX for Dummies Questions & Answers" forum titled "Knowing when a different program modifies a file" (see http://www.unix.com/unix-dummies-questions-answers/221357-knowing-when-different-program-modifies-file.html for the full discussion) where it was pointed out that if someone edits a log file with vim while a daemon has the file open for writing all subsequent output written to the log file by the daemon will be lost until the deamon switches to a new log file (or is killed and restarted).
I understand that renaming a temp file with the changes incorporated is an atomic operation reducing the amount of time that a large file would be in an inconsistent state. and that it widens (or opens) a window where a file could be "damaged" due to an anomalous event (e.g., power failure, lack of disk space, etc.). (But I assume that in these cases, vim's recover command could restore the data after the system is rebooted or space is made available.) I know that when there are multiple hard links to a file, the inode is not changed when vim saves the file updates. Given the above scenario, should vim ever change the inode? Clearly a sysadmin that edits a log file should be retrained or fired, and clearly the POSIX standards state that the results produced when two processes are writing to the same file without exchanging active handles produces undefined results; but the fact that a system daemon would continue writing to a file after vim has unlink()ed it and that all future diagnostics written by that daemon could be lost is scary. - Don -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
