Skip to content

Continue deleting other files when some fail to delete in FileUtils#1103

Open
torusrxxx wants to merge 4 commits intohyphanet:nextfrom
torusrxxx:SecureDeleteAll
Open

Continue deleting other files when some fail to delete in FileUtils#1103
torusrxxx wants to merge 4 commits intohyphanet:nextfrom
torusrxxx:SecureDeleteAll

Conversation

@torusrxxx
Copy link
Contributor

  • secureDeleteAll should delete all files in a directory using secureDeleteAll.
  • Continue deleting other files when some of the files fail to delete in FileUtils.
  • Use distinct temp file names in tests.
  • tests should delete temp directories on exit.

Copy link
Contributor

@bertm bertm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

import java.io.InputStream;
import java.io.OutputStream;

import java.io.*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't collapse imports into wildcard imports.

try (
FileOutputStream fos = new FileOutputStream("output.utf16")
){
new File("output.utf16").deleteOnExit();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the below instances should really use a finally block instead of resorting to JVM shutdown hooks with deleteOnExit.

@bertm
Copy link
Contributor

bertm commented Aug 29, 2025

As a side note: really, these methods should be rewritten using Files.walkFileTree as in their current shape they will follow symbolic links into directories, which is a frightening idea when deleting!

None of that is introduced in this change, so feel free to not do anything about it in this PR.

Also, "secure deleting" is becoming increasingly meaningless in the modern days of copy-on-write filesystems and SSD drives (which are essentially copy-on-write hardware) ... but that's for another day 😉

boolean success = true;
for(File subfile: wd.listFiles()) {
if(!removeAll(subfile)) return false;
if(!secureDeleteAll(subfile)){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if(!secureDeleteAll(subfile)){
success &= secureDeleteAll(subfile);

boolean success = true;
for(File subfile: wd.listFiles()) {
if(!removeAll(subfile)) return false;
if(!removeAll(subfile)){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.


@After
public void tearDown() {
FileUtil.removeAll(dir);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While that is certainly a possibility, JUnit offers a TemporaryDirectory rule that takes care of this automatically; can that be used, maybe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JUnit 5 does not support @Rule. I think we will need to migrate to JUnit 5 and therefore stop using @Rule.

Copy link
Contributor

@Bombe Bombe Aug 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t see a pressing reason to migrate to JUnit 5, JUnit 4 certainly seems to work fine, so @Rule it is — unless it’s more of a hassle than it’s worth (which can happen if lots of objects get constructed before the actual test method is running). 😁

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we still need to migrate to JUnit 5 simply because we will not be using JUnit 4 forever. The migration to vintage engine should start as soon as possible so that new tests don't need to migrate from JUnit 4 to JUnit 5.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uhm, we are still on Java 8, I’m pretty confident that a lot of time will pass until we actually need to migrate to JUnit 5. But even if we do, migrating a TemporaryFolder from a @Rule to a @TempDir is almost trivial.


@Before
public void setUp() {
base = new File("tmp.encrypted-random-access-thing-test");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a member variable is only assigned once and doesn’t depend on anything else and its initialization does not throw an exception, please make the member variable final and assign it in the declaration.

@torusrxxx torusrxxx marked this pull request as ready for review August 30, 2025 14:18
@bertm
Copy link
Contributor

bertm commented Sep 4, 2025

@torusrxxx kindly stop adding to the scope of this PR - if you want to make other improvements, please use a different branch and file a separate PR. This serves two purposes:

  • to prevent delaying the merge of this PR (since every time you add something, it has to be re-reviewed and there may be additional comments unrelated to the original scope, causing further delay)
  • to keep the changelog clean (make it easier to track what changed when and why)

The changes in SerializerTest, ShortBufferTest, and SparseBitmapTest are not at all related to FileUtils or even files in general, please drop those changes for this PR (and feel free to open another PR for them).

dir = new File("split-file-inserter-storage-test");
dir.mkdir();
tempFolder = new TemporaryFolder();
tempFolder.create();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure we should use the method that is documented with “for testing purposes only. Do not use.”

This is exactly the situation I was referring to in my earlier comment about how TemporaryFolder can’t be used during constructor invocation.

@torusrxxx
Copy link
Contributor Author

It looks like part of this pull request will be superseded by #1107. I will have to reopen a new PR.
Also, I haven’t started any meaningful coding with video filters. I have been busy IRL, and unfortunately, work on video filters will likely not be started until at least after Christmas.

@ArneBab
Copy link
Contributor

ArneBab commented Nov 23, 2025

It looks like part of this pull request will be superseded by #1107. I will have to reopen a new PR. Also, I haven’t started any meaningful coding with video filters. I have been busy IRL, and unfortunately, work on video filters will likely not be started until at least after Christmas.

Thank you for the info! And don’t worry: real life must take precedence, otherwise you have little chance to stay active on the long run. I just stumbled over an article that described that burnout is one of the prime reasons for FOSS devs to stop, so keeping the balance is vitally important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants