feat: add a 'copy' synchronization method - #18
Conversation
|
This can also be useful for things like the machine id. The method clearly has downsides, but I'm in favour of adding it with an explicit warning of how this might be less robust than the other methods, and leave it up to users to decide. I was also wondering, maybe we could make copying back optional? I can see situations where you might want to copy over a file into the tmpfs at bootup but never update the source. |
I like the idea and just added an option for that. |
|
Nice, thanks! I'll check the code in more detail later since I'm on mobile now. (I'm not a maintainer on this repo, for the record, so I'm not the one deciding to merge or not, but an independent review never hurts.) |
No problem, a sincere review is always appreciated! |
|
This approach of copying state back to the persistent volume on shutdown is inherently brittle and I don't feel comfortable with adding a feature like this to preservation. Aside from that I'm confused by the actual proposed implementation referring to |
This PR adds a
how = "copy"synchronization method that persists files by copying them from the persistent storage to the root and back.The problem that motivates this PR is that, currently, the two available methods (bind-mounts and symlinks) are not capable of persisting symlinks like
/etc/timezone -> ../etc/zoneinfo/<your_region>. The reason for their failure is that both methods follow the symlink, yet its destination does not exist on the persistent storage.To bridge this gap, this PR adds the copy method: It copies files and directories from the persistent storage to the root on startup and copies them back from the root to the persistent storage on shutdown. The weakness of this method is that it is not resilient against system crashes since in that case, the reverse copy operation is not triggered.