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.
Steve, Can you put the user name in the file name so each user has a separate set if files? David On 6 Jun 2013, at 18:39, Steve Cohen <scohen@javactivity.org> wrote:
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. _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Or put the file in the user's home directory with something like ${user.home} (*Chris*) On Thu, Jun 6, 2013 at 12:58 PM, David Roussel <nabble@diroussel.xsmail.com>wrote:
Steve,
Can you put the user name in the file name so each user has a separate set if files?
David
On 6 Jun 2013, at 18:39, Steve Cohen <scohen@javactivity.org> wrote:
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. _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
The users don't care. These are not "THEIR" files. The only reason for the logs is to debug the application. It has quite complex interactions with a legacy back end and these logs will be necessary for some time as the thing moves into production. Therefore, the solution is to grant all users FULL CONTROL of the files in the directory. Which just goes to show you how silly the Windows permission system is. The users are denied by Group Policy the ability to do anything on these machines other than run this application. They can't even SEE ANY files, get a directory listing, etc. But they "own" these logfiles because they created them. Or more accurately, the application created these files while they were logged on. On 06/06/2013 03:58 PM, Chris Pratt wrote:
Or put the file in the user's home directory with something like ${user.home} (*Chris*)
On Thu, Jun 6, 2013 at 12:58 PM, David Roussel <nabble@diroussel.xsmail.com <mailto:nabble@diroussel.xsmail.com>> wrote:
Steve,
Can you put the user name in the file name so each user has a separate set if files?
David
On 6 Jun 2013, at 18:39, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
> 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. > _______________________________________________ > Logback-user mailing list > Logback-user@qos.ch <mailto:Logback-user@qos.ch> > http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (3)
-
Chris Pratt -
David Roussel -
Steve Cohen