install-eco-mod-source.sh: refuse to rsync pointer-sized .unity3d files #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally filed by @coilysiren on 2026-05-23T19:19:21Z - https://github.com/coilysiren/infrastructure/issues/298
Problem -
scripts/install-eco-mod-source.shrsyncsMods/UserCode/$NAME/from the localeco-mods/eco-mods-publiccheckout into the live EcoServer tree. If LFS smudge is not configured (or LFS objects are not hydrated), the working tree contains 130-byte LFS pointer files where.unity3dassetbundles should be, and the rsync silently breaks the live server.Surfaced - 2026-05-23 incident: 15
.unity3dfiles on the liveeco-serverunit were 131-133 byte pointer files after a 2026-05-22 21:21 deploy. Root cause:git lfs installwas never run at user level, so the post-git lfs migrateeco-modsclone produced pointer files instead of binaries. Repair: surgical rsync from a freshly re-clonedeco-mods(with global LFS hooks now installed) into the live tree.Fix shape - Before rsync, scan the source tree for
.unity3d(or any path matchingfilter=lfsin.gitattributes) under 1 KB. If any are pointer-sized, abort with the offending paths listed and a hint to rungit lfs install && git lfs pull. Same idea applies to.dlland other LFS-tracked extensions if the migration ever widens.Bonus belt - Mirror the same check in
install-eco-mod.shagainst the unzipped release contents, defensive against an upstream release pipeline that ever ships pointers by mistake.Out of scope - The underlying LFS-vs-rollback question for
coilysiren/eco-modsitself. Local repo was re-cloned with global LFS hooks installed, so the immediate footgun is closed; this issue is the belt-and-suspenders.