Matej Vrzala ffb57d1a9b Library lock: Don't write through a link at the owner note's name ...

LibraryLock::acquire wrote catalog.lock.owner with std::fs::write,
which follows a symlink at that name. A library folder someone else
prepared (a shared drive, an unpacked archive, a synced folder) could
carry catalog.lock.owner -> ~/.bashrc or any other file the user can
write, and opening the library replaced that file's content with the
owner JSON. The catalog's staging files had the same problem and were
fixed in #1502; the owner note was missed.

The note is now written through store::create_staging (made
pub(crate)): whatever is at the name is removed (a link itself, never
its target) and the file is created with create_new. Drop already
removed the note with remove_file, which never follows a link.

Test (Unix): a link at catalog.lock.owner pointing at a file outside
the library leaves that file's bytes unchanged through acquire and
drop, and the note lands in the library as a regular file naming this
process.

Reported-by: BS.ehlas.cz

2026-10-22 18:39:33 +02:00

..

examples

Local: forget untouched browse records of folders not browsed for 30 days

2026-10-05 02:26:49 -04:00

proptest-regressions

perf(catalog): #1136 index stacks and album membership, sort keys once per photo

2026-10-11 16:48:16 -05:00

src

Library lock: Don't write through a link at the owner note's name

2026-10-22 18:39:33 +02:00

Cargo.toml

Use chrono instead of hand-rolled UTC conversion (#2457)

2026-10-21 19:36:36 -04:00