Thanks Jeff, that helps. But in this case the rename deletes a file (with the same name) that's still open (and locked), and so the inode is going away, right?
I suppose the OS doesn't care since it was opened read-only, but it sure feels cheesy to me. -- Rod http://www.sunsetsystems.com/ On Monday 24 June 2002 02:45 pm, Jeff Newmiller wrote: > On Mon, 24 Jun 2002, Rod Roark wrote: > > I'm looking at some Perl code (not mine) that does this > > (simplified for clarity): > > > > open(INFILE, "<$filename"); > > flock INFILE, LOCK_EX; > > open(OUTFILE, ">$tempname"); > > flock OUTFILE, LOCK_EX; > > ... > > (read from INFILE, change stuff, write to OUTFILE) > > ... > > rename $tempname, $filename; > > flock OUTFILE, LOCK_UN; > > close(OUTFILE); > > flock INFILE, LOCK_UN; > > close(INFILE); > > > > Notice that it's renaming/deleting files that are open and > > locked. Is this as insane as I think it is? > > No, it is not insane at all, if you are using a *nix-style filesystem. > > Think of rename as "mv"... it doesn't affect the file, rather it alters > the directory entries that point at the file (inode). No deletion is > occurring, and any processes accessing the file are doing so through the > inode, which is unaffected. > > This behaviour allows you to mv a logfile even while it is being written > to, for example. The process writing to the logfile cares not what you > call it, and the next process to attempt to open the logfile finds no > inode for that filename, and creates the new inode as needed. > > I hate the tied data/filename aspect of MSDOS/Windows that makes such > tasks a b***h to implement. _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
