Having versions of a file is a great helper, especially in a collaborative environment. However, we lost some files because the file history was overwritten when the file was overwritten.
Consider this use case (as happened to us a couple of times):
User A creates local FILE, which is synced to NC. He keeps working on FILE and the sync client keeps syncing so that eventually FILE is available in versions 1 through N on the server.
User B, who also syncs FILE overwrites his local copy with a different file. The overwritten FILE gets synced to NC, thereby removing the current and all previous versions of FILE.
A tries to go back to a previous version of his work but finds all versions deleted.
The same thing seems to happen when overwriting FILE through a web interface upload. Oh, and user A can cause the problem all by himself, too.
IMO it would be more logical to save a file that overwrites another as another version of the original file. Is there something I missed here?
Versions will be checked against rules every time when file updated. You can setup more precised rules to not delete versions of files for particular amount of days.
E.g. keep versions at least for 14 days, apply expire rules to all versions that are older than 14 days
Thanks for the update gas85, your infos were most helpful. A quick test proved that overwriting a file will not cause old versions to be deleted when retention obligation is disabled.
To be honest, I still cannot see why the auto setting would kill the file history upon overwriting – but things work for me now and as long as nobody else sees a problem I guess it’s just fine
I tried to reproduce the problem but seem to be unable to.
For the test I went back to 'versions_retention_obligation' => 'auto' and overwrote a file both through the web interface and through sync. The new file was correctly saved as another version of the old file. Old versions were retained.
I removed the setting completely from config.php and repeated the test with no different outcome.
While this seems like good news it also means that there may be a problem that is hard to reproduce. I made sure the behaviour existed before I opened the thread but yesterday’s test files are useless now.
So, case closed for the time but I’d be happier if the problem linked reliably to the solution.
You will lose the file history if the file is first DELETED and then replaced. In some poorly written software, this can happen in the background without you being aware of it.
For example, I ran across a program that when pressing the “save” button, performed the following operation;
rename existing file to temp,
create new file with new data,
validate new file,
4a) If validation fails, delete new file and rename temp file back,
4b) If validation succeeds, delete temp file.
Step 4b destroys nextcloud file history, since it follows the file.
