[logback-user] Problems with delete

Steve Cohen scohen at javactivity.org
Thu Jun 6 19:39:38 CEST 2013


My previous thread showed me being successfully guided to a solution to 
rollover problems, by removing the File element of the rolling policy to 
avoid renaming issues.

These problems surfaced in my instance due the following operational 
environment:

1) A GUI application running under Windows, not a server-side application.

2) Application is launched from time to time by different users.  This 
leads to file-ownership issues preventing rename operation.

Similar problems occur in the delete scenario based on the <maxHistory> 
element.

But in this case, there is no workaround for deletion

Also I wonder about this:

TimeBasedArchiveRemover.cleanByPeriodOffset() calls java.io.File.delete().

File.delete() returns a boolean which is not checked in 
cleanByPeriodOffset().  It also throws a SecurityException (a 
RuntimeException) which isn't checked for.  I'm not sure where this 
would be caught but I'm guessing it isn't the case here or we would have 
more catastrophic failures, so I suppose it's just returning false.

Should logback do something about this?  It's not clear because it's not 
clear what it could do.  There is no alternative as in the case of renaming.

Is there any solution available other than setting the directory so that 
every user has full rights to it?  Mere write access is not enough in 
the Windows permissions scheme.


More information about the Logback-user mailing list