Bug #81078 for Logfile-Rotate: File readable check can cause loss of data

Fri Nov 09 13:52:39 2012 ALUCAS [...] cpan.org - Ticket created

Subject:

File readable check can cause loss of data

Hi, I've been looking into some issues I have been seeing on Windows installations using software which relies on this module. It's worth noting that this issue should affect all platforms. The readable check on the previous log file in the rotate routine, when failed, causes data loss. The log gets truncated without being rotated. If the pre-existing log file is claimed to be not readable for some reason by the system (Windows is really good at that), the existing log file is lost because of this check. If the read check fails, then the following truncation block should also be skipped, probably with a bad return (0) from the routine, or a die. I'm not sure of the best way to fix this? I personally would just skip the check entirely and just leave the -f check, as the system itself will complain if the file really isn't readable. Either that or die. What do you think?

Sun Nov 11 23:06:17 2012 pgampe [...] users.sourceforge.net - Taken

Sun Nov 11 23:13:32 2012 pgampe [...] users.sourceforge.net - Correspondence added

On Fri Nov 09 13:52:39 2012, ALUCAS wrote: Show quoted text

> Hi, > > I've been looking into some issues I have been seeing on Windows > installations using software which relies on this module. It's worth > noting that this issue should affect all platforms. > > The readable check on the previous log file in the rotate routine, when > failed, causes data loss. The log gets truncated without being rotated.

Hi, I was wondering if you could point out for me which 'readable check' you are referring to? Cheers, Paul

Sun Nov 11 23:13:32 2012 The RT System itself - Status changed from 'new' to 'open'

Mon Nov 12 07:25:15 2012 ALUCAS [...] cpan.org - Correspondence added

On Sun Nov 11 23:13:32 2012, PAULG wrote: Show quoted text

> > Hi, > > I was wondering if you could point out for me which 'readable check' > you are referring to? > > Cheers, > Paul

Hi Paul, The line 161 which reads "-r $prev && -f $prev". I think if one of the files isn't readable then it should stop shuffling files, rather than leaving the file in-place to be overwritten on the next run through the loop. This module has been working for me great for the last couple of months, there were just a few strange events which prompted me to start looking for loopholes which would cause files to be overwritten. One other problem I have seen is that the copy on line 169 has no "or croak". With Persist set to 'yes', the script will usually croak before it gets to that line if there are rw issues, but with Persist set to 'no', the file may be truncated without being copied. Regards, Ant