Thanks to visit codestin.com
Credit goes to github.com

Skip to content

fix(versioner): ensure version store dirs remain owner-writable (fixes #10532)#10575

Open
steadytao wants to merge 1 commit intosyncthing:mainfrom
steadytao:fix/staggered-versioner-perms
Open

fix(versioner): ensure version store dirs remain owner-writable (fixes #10532)#10575
steadytao wants to merge 1 commit intosyncthing:mainfrom
steadytao:fix/staggered-versioner-perms

Conversation

@steadytao
Copy link
Contributor

Purpose

Fixes a regression where version-store directories (e.g. .stversions/a/b) can become read-only (0555), preventing Syncthing from creating nested version paths during later archive operations (#10532).

If a parent directory inside the version store loses owner-write permission, subsequent attempts to archive files into deeper paths fail with a permission error. This prevents further versions from being archived for affected folders.

This patch ensures version-store directories always remain owner-writable so nested paths can be created safely.


Changes Made

  • When traversing existing directories in the version store, ensure they remain owner-writable.
  • When creating new directories in the version store:
    • Preserve the original permission behaviour.
    • Explicitly ensure owner-write permission is present to avoid stale read-only states.
  • Add a regression test reproducing the failure scenario where a parent directory inside the version store is read-only and prevents creation of nested paths.

The fix is intentionally minimal:

  • It only adds the owner-write bit if missing.
  • It preserves all other permission bits.
  • It does not alter permission semantics outside the version store path.

Background

Recent permission synchronisation changes caused version-store directories to inherit restrictive permissions from the source folder. In cases where a source directory was read-only (e.g. 0555), the corresponding version-store directory could also become read-only.

Because the version store must create additional nested directories over time, this could leave it permanently unable to archive further versions.

This change ensures version-store directories remain owner-writable while preserving all other permission bits.


Testing

Added a regression test that:

  • Creates a version-store parent directory with mode 0555.
  • Attempts to archive a file requiring creation of a nested directory.
  • Verifies:
    • The archive operation succeeds.
    • The nested directory is created.
    • The parent directory regains owner-write permission.

Additionally verified:

  • Existing permission behaviour for normal archive cases remains unchanged.
  • All versioner tests pass.

@github-actions github-actions bot added the bug A problem with current functionality, as opposed to missing functionality (enhancement) label Feb 14, 2026
@steadytao steadytao changed the title fix(versioner): ensure version store dirs remain owner-writable (fixe… fix(versioner): ensure version store dirs remain owner-writable (fixes #10532) Feb 14, 2026
@calmh
Copy link
Member

calmh commented Feb 15, 2026

The permissions should then be modified for the required duration and restored, like we do while syncing regular changes.

@steadytao steadytao force-pushed the fix/staggered-versioner-perms branch from b31d207 to 1ed20f9 Compare February 16, 2026 01:04
@steadytao steadytao force-pushed the fix/staggered-versioner-perms branch from 1ed20f9 to 18be545 Compare February 16, 2026 01:09
@steadytao
Copy link
Contributor Author

Thank you for the review. I updated the versioner archive path to only temporarily add owner access to version-store directories when we need to create children, then restore the original modes afterwards (including special bits).

I also added/adjusted tests covering:

  • extended TestArchiveReadOnlyVersionsParent to also cover a read-only versions target dir and assert permissions are restored, and
  • added TestArchiveReadOnlySourceIntermediateDir (skipped on Windows) to cover a read-only source intermediate dir case.

Appreciate the guidance, it helped me land on a much cleaner approach

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug A problem with current functionality, as opposed to missing functionality (enhancement)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants