Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Logging to a filehandle of a deleted file

by Marcello (Hermit)
on Feb 28, 2007 at 09:28 UTC ( #602461=perlquestion: print w/ replies, xml ) Need Help??
Marcello has asked for the wisdom of the Perl Monks concerning the following question:

Hello,

I'm implementing a simple logging module for a project but ran into a problem which is probably easy to fix.

I open a filehandle to the logfile which remains open until the long-running process ends. However, the logfile may be removed by another non-Perl process (so a file lock doesn't help here). After this happened, the printing to the filehandle still returns 1 but the file is not recreated again. Here's in short my problem:
use strict; use warnings; my $filename = 'logfile.txt'; open(my $handle, '>>', $filename) or die; unlink($filename); print $handle "First line\n"; syswrite($handle, "Second line\n"); close($handle);
Is there a solution so I can detect that the file does not exists anymore? Both print and syswrite report no errors. Ofcourse I could use (-e $filename) but there's always this chance that the file is removed between the test and the print.

I can use other logging modules out there, but prefer to use my own light-weight module for simple logging.

Any help is as always appreciated! Cheers

Comment on Logging to a filehandle of a deleted file
Download Code
Re: Logging to a filehandle of a deleted file
by varian (Chaplain) on Feb 28, 2007 at 10:18 UTC
    If you link the original file to a backup filename then even while another process deletes the file you can still view the original content plus your additions by using the backup filename. One could even restore the original file, see example below:
    use strict; use warnings; my $filename = 'logfile.txt'; my $backupfile = 'logfile.backup'; open(my $handle, '>>', $filename) or die; link $filename, $backupfile; unlink($filename); print $handle "First line\n"; syswrite($handle, "Second line\n"); close($handle); rename $backupfile,$filename; # ok to fail if $filename still exists unlink $backupfile;
    Note that while your filehandle remains open you can still write to the deleted file. Deleted files will not be visible in directory listings but the open handle would show up on the systems list of open handles (e.g. the command lsof in Lunix and Unix systems would reveal them, provided you have enough system privileges).
    And yes, while you keep writing to that file it will occupy more and more space on disk, a little nightmare for inexperienced system administrators that see disk usage grow and do not know why.
      This looks like a system design fault that cannot be resolved by technical means alone. If the idea is to maximise the survival time of the logging in a hostile environment then perhops the only way would be to reopen the file per log entry. If it's just a question of something else doing the archiving off, then this is definitely only resolvable by redesigning the logging and archiving so that they are aware of each other's needs - in that case flock would indeed help or perhaps combining functionality into the same process.

      -M

      Free your mind

Re: Logging to a filehandle of a deleted file
by Anonymous Monk on Feb 28, 2007 at 10:24 UTC
    On linux, deleting open files is a feature.
      On POSIX, deleting open files is a feature.

      Fixed.</pedant>

      This is documented behavior, BTW. Files-on-disk don't go away despite their link count going to zero until the last process with an open descriptor closes it.

Re: Logging to a filehandle of a deleted file
by cdarke (Prior) on Feb 28, 2007 at 14:11 UTC
    Ofcourse I could use (-e $filename) but there's always this chance that the file is removed between the test and the print.
    It's worse that that. It is possible that another program not only deletes the original file, but creates another instance of it. So the name might exist in the directory, but pointing at a different inode to the one you are using.
    Maybe you should check that the inode number hasn't changed, you can get the inode from stat (assuming you are on *nix).
Re: Logging to a filehandle of a deleted file
by idsfa (Vicar) on Feb 28, 2007 at 14:30 UTC

    cf Re: (OT) place on linux box to safely create tons of temp junk???

    As that node indicates, one solution to retain your information is to rewind your file handle. This works so long as all that you want is for that information to be available to the process which already has the handle.

    On some OSes with /proc file systems, the OS exposes the file handles. In linux, for example, if my PID is 54321, file handle #4 can be found at /proc/54321/fd/4. This "file" can be copied back into the regular filesystem, read by other applications (so long as you have the correct permissions), etc.


    The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://602461]
Approved by Zaxo
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (12)
As of 2014-08-29 19:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (287 votes), past polls