Skip to content

[2.x] fix: Only disable symlinks when truly not supported#8479

Merged
eed3si9n merged 1 commit intosbt:developfrom
MkDev11:fix/symlink-supported-flag-8478
Jan 11, 2026
Merged

[2.x] fix: Only disable symlinks when truly not supported#8479
eed3si9n merged 1 commit intosbt:developfrom
MkDev11:fix/symlink-supported-flag-8478

Conversation

@MkDev11
Copy link
Copy Markdown
Contributor

@MkDev11 MkDev11 commented Jan 11, 2026

fix: Only disable symlinks when truly not supported

What's the problem?

When you delete the disk cache while sbt is running and then recompile, symlinks stop being created. Instead, sbt copies files directly. This happens because the symlinkSupported flag gets permanently set to false during the session.

As @azdrojowa123 discovered through debugging, a FileAlreadyExistsException is thrown during step 5 of the reproduction, and this incorrectly disables symlink support.

Why does this happen?

The current code catches any FileSystemException and assumes it means "symlinks aren't supported on this system." But FileAlreadyExistsException is a subclass of FileSystemException, and it has nothing to do with symlink support - it just means the file already exists (likely a race condition).

What's the fix?

Instead of disabling symlinks on any FileSystemException, we now only disable them when the error message specifically indicates a permission or privilege issue:

  • "privilege"
  • "Operation not permitted"
  • "A required privilege is not held"

This way, transient errors like FileAlreadyExistsException will fall back to copying the file, but won't permanently disable symlinks for the rest of the session.

I also added a check to verify the CAS file exists before attempting to create a symlink, which helps avoid some edge cases.

Fixes #8478


Contribution by Gittensor, see my contribution statistics at https://gittensor.io/miners/details?githubId=94194147

Fix issue where symlinkSupported flag was incorrectly set to false
when any FileSystemException occurred during symlink creation.

Root cause: FileAlreadyExistsException (a subclass of FileSystemException)
was being caught and incorrectly disabling symlinks permanently.

The fix:
- Only set symlinkSupported=false when the exception message indicates
  symlinks aren't supported (privilege/permission issues)
- FileAlreadyExistsException and other transient errors now fall back
  to copy without permanently disabling symlinks
- Add check that CAS file exists before attempting symlink creation

Fixes sbt#8478

Generated-by: Cascade (AI pair programmer)
Copy link
Copy Markdown
Member

@eed3si9n eed3si9n left a comment

Choose a reason for hiding this comment

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

Thanks!

@eed3si9n eed3si9n changed the title fix: Only disable symlinks when truly not supported [2.x] fix: Only disable symlinks when truly not supported Jan 11, 2026
@eed3si9n eed3si9n merged commit 985cf94 into sbt:develop Jan 11, 2026
14 checks passed
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.

[2.x] After deleting the disk cache, the creation of symlinks stops

2 participants