[logback-user] Problems with delete

[Steve Cohen]

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 at diroussel.xsmail.com <mailto:nabble at 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 at javactivity.org
>     <mailto:scohen at 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 at qos.ch <mailto:Logback-user at qos.ch>
>      > http://mailman.qos.ch/mailman/listinfo/logback-user
>     _______________________________________________
>     Logback-user mailing list
>     Logback-user at qos.ch <mailto:Logback-user at qos.ch>
>     http://mailman.qos.ch/mailman/listinfo/logback-user
>
>
>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>