DependencyCheck 10.0.4 tries to lock database directory even when autoUpdate is set to false

[guidoschreuder]

Describe the bug
Switching from version 10.0.2 to 10.0.4 jobs on Jenkins are getting stuck because DependencyCheck 10.0.4 tries to lock database directory even when autoUpdate is set to false.

The dataDirectory is mounted on a read-only filesystem, as we centrally update this cache to keep the NVD API from causing problems by throttling. This has worked well for us, but now this is broken

Version of dependency-check used
10.0.4

Log file
/bin/mvn -X org.owasp:dependency-check-maven:10.0.4:aggregate -DdataDirectory=/owasp-cache/owasp-api-data -DautoUpdate=false
[snip]
[DEBUG] Settings.getDataFile() - file: '/owasp-cache/owasp-api-data'
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:58:23.759)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:58:38.761)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:58:53.762)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:59:08.763)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:59:23.765)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:59:38.774)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 14:59:53.775)
[DEBUG] Sleeping thread main (a39cd3c744de8a843d0095cb26149de3) for 15 seconds because an exclusive lock on the database could not be obtained (2024-10-10 15:00:08.777)
[etc]

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
Do not try to lock the data directory when autoUpdate is set to false

Additional context
Add any other context about the problem here.

[guidoschreuder]

Another detail; previously we used setting the data.h2.directory but that is no longer documented and also does not work for published suppressions, so that was part of the reason for switching

[guidoschreuder]

Ok, just tested this, when using data.h2.directory there is no problem with locking

So my question would then be; is there any way we can use the documented property without running into this locking issue on a RO filesystem?

[guidoschreuder]

Please not that testing with a local folder that is marked read-only does NOT expose this bug, only appears to happen on a RO filesystem

[guidoschreuder]

I suspect the problem lies in the creation of the defensive copy in AbstractSuppressionAnalyzer.loadCachedHostedSuppressionsRules()

A solution would be to have WriteLock always create lock files in Settings.getTempDirectory() instead of Settings.getDataDirectory()

[jeremylong]

A better solution would be to figure out why a lock is being used when autoUpdate=false.