#38 briss DELETES all files in "/tmp"!

[gml]

I just noticed another, far worse, bug in briss: It systematically deletes evrything in "/tmp"!
On my machine, the behavior is 100% reproducible.
When I start briss (java -jar briss.jar /some/file.pdf) the dialog asking for non-merged pages comes up and after i click on any button, the massacre starts:
It reads the directory of "/tmp" and calls "stat" for every entry. Obviously it then checks the modification time of the entry - some very new files stay unmolested. For everything else, it 1st calls "unlink"; for directories, this fails, so it also tries "rmdir" (which also fails for non-empty directories).

[pid 25774] open("/tmp", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 30
[pid 25774] getdents(30, /* 122 entries */, 32768) = 4208
[pid 25774] getdents(30, /* 0 entries */, 32768) = 0
[pid 25774] close(30) = 0
[pid 25774] stat("/tmp/Acme-Ref-0.03", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 25774] unlink("/tmp/Acme-Ref-0.03") = -1 EISDIR (Is a directory)
[pid 25774] rmdir("/tmp/Acme-Ref-0.03") = -1 ENOTEMPTY (Directory not empty)
[pid 25774] stat("/tmp/zim_0.56-1_all", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 25774] unlink("/tmp/zim_0.56-1_all") = -1 EISDIR (Is a directory)
[pid 25774] rmdir("/tmp/zim_0.56-1_all") = -1 ENOTEMPTY (Directory not empty)
[pid 25774] stat("/tmp/.com.google.Chrome.RR5gkQ", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
[pid 25774] unlink("/tmp/.com.google.Chrome.RR5gkQ") = -1 EISDIR (Is a directory)
[pid 25774] rmdir("/tmp/.com.google.Chrome.RR5gkQ") = -1 ENOTEMPTY (Directory not empty)
...

[laborg]

I double checked the java code to not delete anything I didn't create. I guess it is rather a OS specific type of behaviour to clean up the tmp when it thinks is the right time. Unless you can show/prove that any important(used at the moment by another program) temporary file gets deleted I don't think this is a bug.

[gml]

The "OS specific behavior to clean up /tmp" is a well-documented and configurable script that is run at boot time (and my "configuration" consists of completely de-activating the mechanism, because I keep all kinds of files that I have not yet decided what to do with in "/tmp"), but in this case it is something, "briss" does - in case this is unclear: the listing above is the "strace" output of briss (and indeed briss itself - no external programs are called) and this sequence of actions occurs _every time_ when I start briss and will try to delete everything in "/tmp" above a certain age.

It also obviously is not a new bug (after looking closer, I found that the reports about "Briss deletes pdf files when not in the same folder" and " deletes unrelated files" are probably referring to the same issue - so this seems to be around for ~ 2 years and probably only happening on Linux systems). If it is not done in your program code, then it must be something, that one of the libraries you use does - it is (fortunately!) not the usual behavior for java programs on Linux - I've never seen any other program (java or not) doing anything like this.

I know the GPL's disclaimer, but since you think this is not even a bug, you should at least clearly indicate, that the normal program behavior not only includes cropping pdf files, but also deleting a whole bunch of other stuff that you feel is not important enough to keep ...

[gml]

... just out of curiosity, I took a look at the sources:
I am pretty shure, the culprit is "org.jpedal.io.ObjectStore" (which is quite a mess!)

As a quick workaround, start with briss with 'java -Djava.io.tmpdir=/tmp/empydir/ ...'

[Dhekir]

I use briss quite often and such a behavior would annoy me, so I'd like to have more information about this. I tried your steps with briss 0.9 and I could not reproduce it. After running briss several times, the files in /tmp remain there, even a few cropped<random number>.pdf created by briss. Running strace does not show any occurrences of unlink/rmdir. I'm running Fedora 13 64-bits.

[Berteh]

bug confirmed on Ubuntu 12.10, java 1.7.0_15-b03. This is a quite serious problem I think.

To reproduce simply add some "old" file in /tmp (eg "touch -d yesterday /tmp/ImHereSinceYesterday.txt"). Making it old is required as recent files are not deleted.

Briss removes this file after clicking "cancel" on the dialog asking for pages to exclude.

... and Briss does not remove it's own "garbage" tmp files in the same directory by the way.

[Berteh]

to be more accurate: Briss removes old files in /tmp even if they are currently in use (following is sample bash code working on Ubuntu 12.10)

echo "blah blah" > /tmp/Imthereforlong.txt
touch -d yesterday /tmp/Imthereforlong.txt
gedit /tmp/Imthereforlong.txt &
java -Xms128m -Xmx1024m -jar /opt/briss-0.9/briss-0.9.jar ~/Docs/book.pdf

The file /tmp/Imthereforlong.txt is removed by Briss after clicking on "cancel" in dialog asking for pages to exclude.

[Dhekir]

I confirm the bug, indeed it does not delete recent files, only older ones, even if they are currently being used by processes such as gedit or kate. I hadn't noticed it because I had rebooted the machine so all my files in /tmp were recent, but using touch -d clearly shows it happens.
It is VERY bad practice to simply delete all files in a directory which does not belong to the process nor has been created by it, even if it is /tmp.