mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-18 16:13:51 -06:00
7c6cfeecfd
copyFileBytes replaced fs.copyFileSync because copyFileSync does not merely copy bytes - it fchmods the destination to match the source, and exFAT has no permission bits, so the pre-migration snapshot failed with EPERM on a player. The replacement dropped the chmod entirely, which fixed that and introduced a worse problem everywhere else: the copy landed at the default 0666 & ~umask. Measured on ext4, a 0600 database file copied to a 0664 snapshot - the whole database readable by group and other, on every install, not just on a player. Removing a permission operation to fix a permission error is not a fix. The mode is now applied as a separate, failure-tolerant step after the bytes are written. That is the actual difference from copyFileSync: there the chmod is inseparable from the copy, so a filesystem without modes fails the whole operation; here the data is already safe and a refusal simply means there were never permissions to carry across. Two tests: the source mode survives the copy (fails on the current main), and a filesystem that refuses fchmod still gets its bytes. Claude-Session: https://claude.ai/code/session_014kfhrUPit5MCqxeTQyqr56 Co-authored-by: Dan Walters <dan.walters@bytetinker.net> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| config | ||
| db | ||
| lib | ||
| middleware | ||
| player | ||
| routes | ||
| scripts | ||
| services | ||
| test | ||
| ws | ||
| .gitignore | ||
| config.js | ||
| node_modules | ||
| package-lock.json | ||
| package.json | ||
| server.js | ||
| smoke-ui.js | ||
| version.js | ||