[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