refactor(config): remove allow_symlinks_on_windows flag#607
Merged
Conversation
Drop the Windows-specific opt-in guard around os.Symlink in both the importer post-processor and the health regeneration handler. Symlink creation now always calls os.Symlink directly; any Windows privilege error surfaces as a normal OS error to the caller. Removes the flag from the Go config struct, YAML sample, frontend types, and the Workers UI control.
Closed
4 tasks
fatbob01
added a commit
to fatbob01/altmount
that referenced
this pull request
May 22, 2026
javi11#607 removed the guards in symlink_creator.go and health_handlers.go but two more remained: - internal/config/manager.go: validator rejecting SYMLINK on Windows at startup - internal/health/library_sync.go: guard blocking symlink updates in library sync Remove both blocks and their now-unused runtime imports. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3 tasks
javi11
pushed a commit
that referenced
this pull request
May 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
allow_symlinks_on_windowsopt-in flag from the config schema, YAML sample, frontend types, and Workers UI.os.Symlinkguard (windowsSymlinkAllowed) from the importer post-processor; both call sites now callos.Symlinkdirectly.runtime.GOOS == "windows"block frominternal/api/health_handlers.go(library file regeneration) so it matches the importer behavior.runtimeimport from both Go files and the toggle + warning alert fromWorkersConfigSection.tsx.Why
The importer respected the user's opt-in, but the health regeneration handler ignored the flag entirely and always errored on Windows — two different behaviors for the same OS-level operation. Collapsing both paths to call
os.Symlinkdirectly makes a Windows symlink failure (when Developer Mode isn't on, or the user lacks the privilege) surface as a normal OS error, matching every other filesystem call in the codebase.Test plan
go build ./...cleango vet ./...cleanAllowSymlinksOnWindows/allow_symlinks_on_windows/windowsSymlinkAllowedreferencesbun run check(not run —node_modulesnot installed in the worktree; changes are pure field deletions with all references removed)import_strategy: SYMLINK, triggerPOST /api/health/regenerate-symlinkson Linux — symlinks created as before