Bug 29726 - DailyRollingFileAppender : log4j:ERROR Failed to rename
Summary: DailyRollingFileAppender : log4j:ERROR Failed to rename
Status: RESOLVED FIXED
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Appender (show other bugs)
Version: 1.2
Hardware: PC All
: P3 critical
Target Milestone: ---
Assignee: log4j-dev
URL:
Keywords:
: 900 13021 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-06-21 19:55 UTC by julien2412
Modified: 2007-09-04 05:10 UTC (History)
3 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description julien2412 2004-06-21 19:55:39 UTC
I've had this error today so i've cleared the directory where there are all the
logs, it's worked.
So i tried to reproduced the pb by doing this :
- change the windows date (2 days before)
- create a log file in the log directory (with a name used by an appender)
- change the windows date (normal date)
- i start the server on wsad (5.1.1) and retry a log test -> error

i use Windows 2000 sp4 with wsad 5.1.1 fix 003, log4j 1.2.8 (not modified)

Any ideas ?
Comment 1 Brian Burch 2004-11-29 15:22:15 UTC
This is definitely a "bug" in the java.io.File.renameTo() method.

Sun think they have closed this problem in J2SE 5.0 (4167147) by changing the
specification!!! Not much help to those of us in the real world, because they do
not provide an alternative method.

I've encountered the same symptoms with my webapp running under Tomcat on
Win2kServer, WinNT4 and OS2. All 3 have "lazy write" file systems and seem to
refuse the rename of the closed file becaase "it is busy". I've not encountered
the same symptoms running my other log4j applications that do not use Tomcat,
but perhaps I've just been lucky so far?

There is a good workaround under the duplicate bug 13021. However, this
workaround does not take account of the fact that BOTH DailyRollingFileAppender
and RollingFileAppender (and others?) use java.io.renameTo(). We need a more
generalised solution.

I've coded a new "utility" superclass instance method
FileAppender.safeRenameTo(String newName) based on the copy-and-zap-original
strategy proposed in bug 13021. I've also coded changes to
DailyRollingFileAppender and RollingFileAppender to use the new utility method.
However, I don't like the change to RollingFileAppender because it copies every
"old" log file to its new name... but at least it is safe!

I'm happy to donate my changes, provided the committer for these classes thinks
they are worth consideration. Please let me know.


Comment 2 Yoav Shapira 2004-12-10 18:20:48 UTC
*** Bug 13021 has been marked as a duplicate of this bug. ***
Comment 3 Mike O'Keefe 2005-01-12 19:05:02 UTC
This seems to be similar or a duplicate of 900
Comment 4 Patrick Taylor 2005-02-04 22:40:29 UTC
Several suggestions on the proposed fix:

Only do the copy/zap if File.renameTo() fails.  Renaming is much cheaper when it
works, particularly if the log file is large.

If both the renaming AND copying fails, the new log file should be opened in
append mode.  This ensures that the existing log messages are not lost.

Be careful about how the copying is done.  It's safer and more efficient to do a
binary copy using a reasonable buffer size rather than try to do a
line-at-a-time text copy.
Comment 5 Ceki Gulcu 2005-02-22 23:24:21 UTC
This bug should be fixed in log4j version 1.3.
Comment 6 Mike O'Keefe 2005-03-07 20:08:49 UTC
*** Bug 900 has been marked as a duplicate of this bug. ***
Comment 7 Steve Hahn 2006-11-28 11:08:26 UTC
(In reply to comment #5)
> This bug should be fixed in log4j version 1.3.

We are currently experiencing this problem with version 1.2.8 on Windows 2000.  
We are hesitant to move log4j 1.3 alpha into production.  What other options 
are there?  Is there a fix for 1.2.x?
Comment 8 Claude Vedovini 2007-01-04 00:32:19 UTC
Ceki, could you please confirm this bug is actually fixed in 1.3 and not in any
1.2.x version?
Thx
Comment 9 Claude Vedovini 2007-01-15 08:16:30 UTC
(In reply to comment #5)
> This bug should be fixed in log4j version 1.3.

Ceki, could you please confirm this bug is actually fixed in 1.3 and not in any
1.2.x version?
Thx
Comment 10 arnauldvm 2007-09-04 05:10:09 UTC
I checked myself, and found it was solved only in 1.3 for DRFA.
For RFA, it has been solved in 1.2.15 too (see bug 41735).

On another hand, now 1.3 has been abandoned. But its
o.a.l.rolling.RollingFileAppender, that solved the problem,
is available in companions / extras, which release 1.0 has
been recently released.

Please note that, though RFA and DRFA are deprecated in favor
or o.a.l.rolling.RFA in 1.3, they are not deprecated in 1.2.15.