fix(windows): enable SYMLINK import strategy on Windows with allow_symlinks_on_windows flag

[fatbob01]

Summary

Three related bugs prevented the SYMLINK import strategy from working on Windows even when the user explicitly set allow_symlinks_on_windows: true. All three need to be fixed together for Windows symlink support to work end-to-end.

Bug 1: viper/mapstructure silently drops *bool fields (config/manager.go)

viper.Unmarshal leaves pointer-to-bool (*bool) fields as nil when the key is present in the YAML config but mapstructure cannot resolve it to a non-nil pointer. This means AllowSymlinksOnWindows is always nil after startup even when set to true in the config file.

Fix: Added a viper.GetBool fallback after Unmarshal in both reloadConfig and LoadConfig to ensure the field is always populated from the actual config value.

Bug 2: Validator blocks SYMLINK on Windows unconditionally (config/manager.go)

The config validator returned an error for any Windows + SYMLINK combination without checking the AllowSymlinksOnWindows opt-in flag.

Fix: Only reject when AllowSymlinksOnWindows is nil or false.

Bug 3: handleRegenerateLibraryFiles ignores the flag (api/health_handlers.go)

The Regenerate Library Files handler hardcoded "symlinks not supported on Windows" regardless of the flag, blocking the feature even when explicitly enabled.

Fix: Check AllowSymlinksOnWindows before blocking symlink creation.

Bonus: AllowSymlinksOnWindows missing from API response (api/types.go)

The field was not included in ImportAPIResponse / ToImportAPIResponse, making it invisible in API responses and causing confusion about whether the config was loading correctly.

Notes

• Requires Windows Developer Mode to be enabled for os.Symlink to succeed (Windows OS requirement)
• Discovered and fixed while setting up altmount on Windows with import_strategy: SYMLINK — confirmed working end-to-end after these fixes
• I am not a developer; these fixes were identified and implemented with the help of Claude AI

Test plan

• Set import_strategy: SYMLINK and allow_symlinks_on_windows: true on Windows with Developer Mode enabled — altmount should start without validation error
• Confirm GET /api/config response includes allow_symlinks_on_windows: true in the import section
• Confirm Regenerate Library Files creates symlinks successfully on Windows
• Confirm leaving allow_symlinks_on_windows unset or false still blocks SYMLINK on Windows with a clear error message

[javi11]

Instead of adding a new config allow_symlink_in_windows can you just relay on the symlink enabled config and just remove the windows limitation?

[javi11]

im removing the flag here #607 and just using the symlink, sorry about adding the flag in the first place

[fatbob01]

Thanks for the feedback and for implementing a cleaner fix directly! Agreed that removing the guard entirely is better than gating it behind a flag. Also good catch that the health handler was ignoring the flag anyway. Appreciate the quick turnaround!