Tinylog Android, is it possible to clear the file? - java

I'm using the Tinylog library with the "rolling file" function to write logs to a file. Sometimes I need to clear a file.
Tried to do it with normal Java methods but it breaks the file and makes it hard to read.
Is there a way to clear the log file at any point so it doesn't break?

You can use standard policies for starting new log files at defined events. This is the recommended way.
If you need more flexibility, you can use the DynamicPolicy for starting a new log file programmatically. This policy is part of tinylog 2.5. The first milestone is expected to be released during this month and will include this new policy.
Configuration:
writer = rolling file
writer.file = foo.log
writer.policies = dynamic
Start new log file in Java:
DynamicPolicy.setReset();

Related

Disable creation of .orc.crc file

I am working with the apache orc-core java api. I have noticed a couple of things and was wondering if there are options to control them
Does not overwrite files. The call to OrcFile.createWriter fails if the specified file already exists. Is there an option to get it to overwrite by default?
Generates .crc files. If I write to a file called test.orc the program also creates a file called .test.orc.crc. Is there an option to disable this?
I know I can work around both of these simply by deleting the relevant files in the code. Was just wondering if there was a "proper" way.

Manage error log in Java

I have an issues with the file Error.log which is generate by Java.
It's too big (Currently >10Go) I can't open it with Notepad++/SublimeText etc.. and as it's on a dedicated computer, transfering it with Teamviewers make Teamviewer crash.
I would like to know if there is a way to configure how the error.log file is generated.
I want to have one file each days and only keep the last 7 days.
Can I configure Java to do that ? Or do I need to redirect System.err to a file ?
Thanks.
There are some java libraries you can use to manage log files the most popular log4j. So if you can edit the source code, this library can help achieve what you want. Besides that there are some tools that can handle large log files and give you search functionnality, edit reports and so on. try look for splunk, elasticsearch, kibana ..
If you have source code available just change log4j configuration. If not then try following
create a job which checks consistently to the log file and rename this when size exceeds some configurable value.

How to avoid log4j output external modification

I had a request to find a solution for making a log file secure from editing from the user (not root user) running the JBoss instance of an application (Linux environment)
First idea I had is to use the chattr +a from root user to allow only the appending of new raw in the log file.
But the Log4j file is configured to rotate the file each day and for this reason I suppose that I should repeat the chattr command for each file created everyday.
I also not sure that the past day file in its "append only" state can be zipped from rotation.
Any suggestion or alternative way to proceed is welcomed.
One way is to create your own "daily rolling file appender". In a similar situation, I created a file appender based on the CustodianDailyRollingFileAppender (see for more information the answers in this question). Put your custom version in a "log4j-custom.jar" and place that in the JBoss common lib-directory. Last step is to update the log4j-configuration file to use the custom file appender.
In your custom file appender you can execute commands (1) to change the file-attributes before and after rolling log-files. Make sure to test your custom rolling file appender with "corner cases" like "there are no previous log-files": I found a couple of (easy to solve) bugs in the original custodian appender.
(1) Or use the new Java 7 POSIX file system options.

multiple log files being generated

I have written an application wherein I am downloading email and logging details in a file called my.log using a filehandler.
FileHandler handler = new FileHandler("my.log",5242880,1,true);
loggerObject.addHandler(handler);
Although the logging is happening correctly, multiple files like my.log.1 ,my.log.2 etc. are being generated in the same directory .They arent temporary and remain there even after the program stops executing.
Why are they being generated and how can I prevent this?
Look at the documentation for FileHandler and you will see a number is added for file conflict resolution. If there is an existing file, the %u marker in the pattern will be replaced with the next available number. If there is no %u marker then it is added to the end of the filename.
To avoid this, you need to make sure you close the previously opened file when you have finished writing to it.

Notify a Button if the number of files in a directory change

I have a button that I want to disable as long as there isn't a specific number of files in a directory.
Is there some kind of listener that notifies me at the moment a file is created or deleted in a directory?
There's no current native support in Java for file system events and monitoring. JNotify is a useful library for doing this. You should set it up to monitor the directory for modifications, and then determine yourself what's been added/removed.
Java 7 will have file system event support built into it.
One thing you might want to consider - If you're listening for creation events then you'll want to make sure that the file is completely written before you start reading it. I'm not sure what type of support Java 7 will offer for this problem.
I've implemented mechanisms like this in the past and this particular problem required special handling. If you are controlling both the file reader and writer then you can get around this with naming conventions, etc. (the writer names the file xxx.prt and renames the file when it's done being written). Since I didn't have control of the writer I had to add another polling mechanism to check the file size on an interval to make sure each new file was actually ready to be read. Not a perfect solution, but was sufficient for my case.
My two cents...

Categories

Resources