Spontaneous deletion of folder(s), bypassing Deleted files

[iGadget]

As per my Jos Poortvliet's response to my post on Google+ (https://plus.google.com/communities/101550101068949663712/stream/272ce5fa-542a-480d-8428-560beccc8f46), I'm now filing this as a (potential) bug.

On July 28th, I upgraded my ownCloud server (running on Ubuntu server 14.04 x86_64) to version 8.1.0.

Yesterday (July 29th), I saw the ownCloud client (v 1.8.4. on Ubuntu 14.04 x86_64) reporting it had deleted an entire folder out of the blue.
I did not initiate the deletion of this folder, so I went to the web interface, where I noticed it had been deleted from the server as well.
However, when I looked at 'Deleted files' in the web interface, the deleted folder was not present there either...

My client log showed this at the time the folder was deleted:
"29-07-15 19:35:02Werk/2015/TAD ownCloud Deleted"

My server log showed no event at the time the folder was deleted. In fact, there seems to be no logged event on July 29th whatsoever(!).

The specific folder was on local storage, nothing fancy. Fortunately, I was able to restore it from a backup, so in the end I did not loose any data (just a fair amount of time).
But this event makes me paranoid about which folder will be spontaneously deleted next...

If there's any info I can provide to help catch the cause of this unfortunate event, please let me know.

[jospoortvliet]

@rullzer this is what I discussed with you on IRC. How can we track this down, it sounds scary..

[PVince81]

@iGadget did you rename a big folder ?
Do you remember whether the files were still present in the "data" folder ?

[PVince81]

Was it only the content of the folder ?
Could be #13391

[iGadget]

@PVince81 as a matter of fact, I did rename the parent folder '2015' by mistake on the 28th, right after I upgraded to 8.1.0. So that was a day before losing the entire 'TAD' folder (not just the content).

What happened was that I discovered the 'favorites' feature on the web GUI, added the '2015' folder to my favorites and mistakenly assumed that this would be a shortcut which I could rename, just as in Nautilus. Within half a minute I realised my mistake and renamed it back to the old name. Luckily (at least, that's what I thought then), the ownCloud client hadn't picked up the change yet so everything seemed fine at that point.

I guess that in the background, things did go bad then?

[PVince81]

Yes, that manipulation likely caused the issue you saw which matches #13391 😦

In 8.1 with transactional locking enabled (https://doc.owncloud.org/server/8.1/admin_manual/configuration_files/files_locking_experimental.html) it will lock the folder and prevent further operations on it while the rename operation is still happening.

Closing as duplicate.

[iGadget]

Sorry for not trying this sooner, but today I SSH'd into my ownCloud server and noticed that the lost folder is actually still present on the file system. So to rectify - no data was actually lost, it's just not accessible trough the ownCloud UI's.

So how would I force a re-scan of the files that are actually present on the filesystem?

[PVince81]

sudo -uwww-data ./occ files:scan username.
Replace username with the user name of the user for who to rescan.
Replace "www-data" with the web server user if different.

[iGadget]

My server doesn't allow me to execute php files directly, so
sudo -u www-data php ./occ files:scan username
did the trick. Thanks!