l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Jun 25 06:47

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Perl question: file handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Perl question: file handling

On Mon, 24 Jun 2002, Rod Roark wrote:

> 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?

No, deletion does not trigger removal of the inode directly. Only the
elimination of all references to the inode triggers deletion of the
inode.  The rename does eliminate the directory entry pointing to the old
inode, but the open file implies another reference, so it doesn't go away
until that file handle is closed.

> I suppose the OS doesn't care since it was opened read-only, 
> but it sure feels cheesy to me.

It feels correct to me.  Any other sequence of operations could allow
another process to get in and stuff data into the file that might then be
destroyed by this process.

> -- 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
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.