Problem

DefaultThumbnailManager.removeThumbnail() blocks indefinitely when the Win32 RemoveDirectory0 native call stalls during thumbnail cleanup on attachment update. The call chain from ThumbnailRemovingListener.handleAttachmentUpdateEvent() through removeThumbnailsOfAllVersions() to FilesystemPathImpl.deleteFileAndPrune() to Files.delete() is fully synchronous with no timeout, no interrupt check, no retry, and no fallback. When the filesystem stalls (e.g., another process holds an open handle to the thumbnail directory), the Caesium async event dispatcher thread blocks indefinitely, causing all subsequent AttachmentUpdateEvent listeners to queue up behind it. This results in attachment saves (particularly draw.io diagrams on second-and-subsequent publishes) hanging or timing out for end users.

Additionally, removeThumbnailsOfAllVersions has no short-circuit conditions. It never checks MIME type, file size, file count, or whether the attachment actually supports thumbnails before calling the blocking delete. The only guard is attachment == null.

Environment

• Confluence Data Center 9.x

• Windows Server 2022

• Shared home on Windows DFS namespace (SMB)

• draw.io plugin (triggers the code path, but the defect is in Confluence core)

Steps to Reproduce

Upload a draw.io diagram to a Confluence page and publish. This succeeds because no prior thumbnail exists on disk.

Edit the same diagram and publish again. This triggers removeThumbnailsOfAllVersions for the prior version's thumbnail folder.

If any process (AV scanner such as SentinelOne, Windows Search Indexer, DFS Replication service) holds an open handle to the thumbnail directory at the moment of deletion, the RemoveDirectory0 call stalls indefinitely.

Note: The issue is intermittent and environment-dependent. It cannot be reproduced outside of environments where an external process holds directory handles during the delete window.

Expected Results

removeThumbnail() should not block indefinitely. If the filesystem delete cannot complete within a reasonable time, it should time out, log a warning, and move on. Thumbnail data is non-critical and can be regenerated on demand. A failed or stalled delete should never block the Caesium event dispatch pipeline.

Actual Results

The Caesium-1-1 thread becomes stuck in RUNNABLE state indefinitely:

"Caesium-1-1" #330 daemon prio=1 os_prio=-2 cpu=1836484.38ms elapsed=230406.96s tid=0x000002223472ccc0 nid=0x1a90 runnable  [0x0000005fe78fd000]
java.lang.Thread.State: RUNNABLE
at sun.nio.fs.WindowsNativeDispatcher.RemoveDirectory0(java.base@17.0.14/Native Method)
at sun.nio.fs.WindowsNativeDispatcher.RemoveDirectory(java.base@17.0.14/WindowsNativeDispatcher.java:147)
at sun.nio.fs.WindowsFileSystemProvider.implDelete(java.base@17.0.14/WindowsFileSystemProvider.java:253)
at sun.nio.fs.AbstractFileSystemProvider.delete(java.base@17.0.14/AbstractFileSystemProvider.java:105)
at java.nio.file.Files.delete(java.base@17.0.14/Files.java:1152)
at com.atlassian.dc.filestore.impl.filesystem.FilesystemPathImpl.deleteFileAndPrune(FilesystemPathImpl.java:71)
at com.atlassian.confluence.pages.thumbnail.DefaultThumbnailManager.removeThumbnail(DefaultThumbnailManager.java:338)
at com.atlassian.confluence.event.listeners.ThumbnailRemovingListener.removeThumbnailsOfAttachment(ThumbnailRemovingListener.java:61)
at com.atlassian.confluence.event.listeners.ThumbnailRemovingListener.removeThumbnailsOfAllVersions(ThumbnailRemovingListener.java:55)
at com.atlassian.confluence.event.listeners.ThumbnailRemovingListener.handleAttachmentUpdateEvent(ThumbnailRemovingListener.java:38)

Editing and publishing attachments hangs or times out. The user experience is a save that never completes.

Workaround

Option 1 (preferred, zero production risk): Identify the handle holder using Sysinternals during a live hang. Run handle.exe /accepteula as Administrator on the DFS file server and search for open handles to the Confluence thumbnails directory:

• If SentinelOne: add the Confluence shared home thumbnails path to SentinelOne's exclusion list.

• If Windows Search: exclude the Confluence share from Windows Search indexing.

Option 2: Bypass the DFS namespace by switching the shared home path from the DFS address to a direct target address.