[vox-tech] Perl question: file handling

[Rod Roark]

Thanks Jeff, that helps.  But in this case the rename deletes
a file (with the same name) that's still open (and locked),=20
and so the inode is going away, right?

I suppose the OS doesn't care since it was opened read-only,=20
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 th=
e
> inode, which is unaffected.
>
> This behaviour allows you to mv a logfile even while it is being writte=
n
> 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.