I have a setup with a `server` and a `client`. The server hosts many files and only a few of them are interesting on the client at any given time so `server` has a folder `pool` which is synchronised to `client` via ST and another folder `archive` which is not. For sharing, a file is moved from `archive` to `pool`; for stopping the opposite operation is done.
We use this setup productively for working on a common set of files. I reality we have more than one client and files to be shared or not reside in folders but this seems not relevant for describing the problem.
Assume `pool` has a file that is up-to-date with `client`. `client` is nomadic so after synchronisation networking may be interrupted. During this time, the file is archived on `server`, thereby stopping synchronisation on that file. `client`, having no way of taking notice, makes a change to the local file, leaving it in its version of `pool`.
Later `client` reconnects to `server` and tries to synchronise `pool`. This is successful as all files in `pool` on `server` are up-to-date with `client` and the edited file on `client` is no longer synchronised to `server`.
Both systems assume to be in sync but are not. No warning message is output on either side and nobody notices there might be a problem. Should `server` decide to move the file back to `pool`, the changes made on `client` will be overwritten without notice as the server version is more recent than the version on `client`.
Is this normal or just a weird setup of mine? Any idea to prevent this?
The only thing I could think of is to use the (very capable) REST API to make sure that (a) `client` is online and (b) the specific file is up-to-date and only then move it to `archive`. However, finding the perfect time for archiving will be increasingly hard with the number of nomadic clients.
We are working on projects. A project has at least one job and it may take several years until another job arrives for the same project. If you work on a job, you will want to see what work was done on other jobs in the same project. If a job is active, several people may work on it and so we use ST’s capabilities for synchronising between everybody, which works quite fine.
It would take a lot of disc space and cause a lot of network traffic if we kept all project data for all jobs distributed to all workstations. So we move data from inactive projects out of the way and do not synchronize it. I believe this should be a rather standard use case, shouldn’t it?
Possibly you are misled by the word archive, maybe you want to consider it as cold standby or idle data. pool is really just a sliding window over the project data we keep.
Side note: following another user’s suggestions we might add read-only SMB access to archive such as to support browsing through reference project data.
I first rename the file in question by prepending it with a dot. This makes the file quite invisible on a Mac unless you know what you are doing - and then you already know what you are doing.
Via the API I can check if all clients have synced. During the waiting time, no file change is to be expected as nobody will be able to see it.
Once everybody has the most recent version it will be safe to remove the file from synchronisation.
This still leaves open the possibility that a device just does not connect and therefore never gets synched. But in that case I can still just cut that device off the latest version and move the file.
