When determining whether a LockableFile is stale, the file's creationtime is used. This causes some issues in Windows when filesystem tunneling is enabled, as the creation time is unlikely to change for commonly-used lock files, such as recently_used.cache.lock.
We have noticed this when running multiple instances of OpenWebStart, where both processes are populating the cache at the same time. This results in a state where both processes claim ownership over the cache lock.
Attached are log files from a modified OpenWebStart jar. These logs only include log messages from LockableFile for clarity and security. I added a log message to determine what the creation time of the file and the current time were when a stale lock file was detected. Note that each time the stale lock is detected, the creation time of the file remains the same, and matches the time the file is first created in the first line of 2023-07-04_15_03_33.38-ows-stage1.log.
Two low-impact solutions to this issue:
When creating the lockFile, explicitly set the creation time with BasicFileAttributeView.setTimes()
Use BasicFileAttributes.lastModifiedTime() to determine whether a LockableFile is stale instead of creationTime.
IcedTea-Web version: 2.0.0-alpha23 OpenWebStart version: 1.5.2 JDK: Azul 1.8.0u322 OS: Windows 10
When determining whether a LockableFile is stale, the file's creationtime is used. This causes some issues in Windows when filesystem tunneling is enabled, as the creation time is unlikely to change for commonly-used lock files, such as
recently_used.cache.lock.We have noticed this when running multiple instances of OpenWebStart, where both processes are populating the cache at the same time. This results in a state where both processes claim ownership over the cache lock.
Attached are log files from a modified OpenWebStart jar. These logs only include log messages from LockableFile for clarity and security. I added a log message to determine what the creation time of the file and the current time were when a stale lock file was detected. Note that each time the stale lock is detected, the creation time of the file remains the same, and matches the time the file is first created in the first line of 2023-07-04_15_03_33.38-ows-stage1.log.
Two low-impact solutions to this issue:
BasicFileAttributeView.setTimes()BasicFileAttributes.lastModifiedTime()to determine whether a LockableFile is stale instead of creationTime.2023-07-04_15_03_33.38-ows-stage1.log 2023-07-04_15_03_33.38-ows-stage2.log 2023-07-04_15_03_33.616-ows-stage1.log 2023-07-04_15_03_33.616-ows-stage2.log