Click during directory rename causes the content to disappear in web browser

[ati562]

Steps to reproduce

1. Create directory \dirA containing at least 30 images with size altogether 30 MB
2. Rename directory \dirA in the browser to \dirB
3. Click (open) a different directory (e.g. \otherDirectory) while the previously mentioned directory \dirA is being renamed (the progress circle is spinning)
4. Return to the root directory \

Expected behaviour

• \dirB is displayed once
• If the renaming is still in progress, the spinning circle should be present
• If the renaming is finished, the spinning circle for \dirB should not be present

Actual behaviour

• \dirB is displayed twice in the browser and both of them are having 0 KB size
• When opening the first \dirB -> it is empty
• When returning to root directory \ only one \dirB is displayed and it is also empty
• When I check the directory on the server via SSH, the files are present -> they are just not shown in the browser
• Issue is reproducible on https://demo.owncloud.org/

Server configuration

Operating system: Debian GNU/Linux 7.8 (wheezy) 64bit

Web server: Apache/2.2.22

Database: mysql Ver 14.14 Distrib 5.5.43, for debian-linux-gnu (x86_64) using readline 6.2

PHP version: 5.4.39

ownCloud version: (see ownCloud admin page) 8.0.2 (stable)

Updated from an older ownCloud or fresh install: Updated

List of activated apps: activity, calendar, contacts, deleted file, external storage support, file locking, mail template editor, pictures, share files, tasks, text editor, versions

The content of config/config.php:

'xxx', 'passwordsalt' => 'xxx', 'trusted_domains' => array ( 0 => 'mydomain.com', ), 'datadirectory' => '/var/www/owncloud/data', 'dbtype' => 'mysql', 'version' => '8.0.2.0', 'dbname' => 'databasename', 'dbhost' => '127.0.0.1', 'dbtableprefix' => 'oc_', 'dbuser' => 'databaseuser', 'dbpassword' => 'xxx', 'installed' => true, 'forcessl' => true, 'mail_from_address' => 'noreply', 'mail_smtpmode' => 'php', 'mail_domain' => 'mydomain.com', 'theme' => '', 'maintenance' => false, 'logtimezone' => 'Europe/Bratislava', 'logfile' => '/var/log/owncloud/owncloud.log', 'loglevel' => 2, 'log_authfailip' => true, 'log_rotate_size' => '100 MiB', 'default_language' => 'sk_SK', 'enable_previews' => true, 'preview_max_filesize_image' => 50, 'apps_paths' => array ( 0 => array ( 'path' => '/var/www/owncloud/apps', 'url' => '/apps', 'writable' => false, ), 1 => array ( 'path' => '/var/www/owncloud/apps2', 'url' => '/apps2', 'writable' => true, ), ), 'appstoreenabled' => true, 'appstoreurl' => 'https://api.owncloud.com/v1', 'secret' => 'xxxxxx', 'forceSSLforSubdomains' => true, ); **Are you using external storage, if yes which one:** no **Are you using encryption:** no **Are you using an external user-backend, if yes which one:** no ### Client configuration **Browser:** Firefox 37.0.2 **Operating system:** Windows 7 64 bit ### Logs #### ownCloud log (data/owncloud.log) {"reqId":"06fa666a5820435072f3f5d37ea0c570","remoteAddr":"xx.xx.xx.xx","app":"PHP","message":"Undefined index: \/var\/www\/owncloud\/data\/xyz\/files\/dirB at \/var\/www\/owncloud\/apps\/files_locking\/lib\/lockingwrapper.php#140","level":3,"time":"2015-05-01T00:50:54+02:00"}

[PVince81]

Thing is, we cannot detect whether a rename (or any other operation) is in progress when going back to the original folder. We could keep it cached, but that sounds a bit like overkill. Also if you go to that folder in a separate browser window, you'd get the same symptoms as you have now.

I think the reason why you see the files on disk but not in the web UI is because the database has not updated yet. This fix #13948 will make it faster in 8.1 and reduce the time window for this discrepancy.

Hopefully high level file locking #11804 will also make such discrepancies disappear from the user's point of view.

[ati562]

Thank you for trying to help with this.

I would like to add just several details. The use-case for reproduction (in bug description) was just a simple use case. I first noticed this issue when I was trying to rename a folder with a lot of files and sub folders. The operation took really long (I was presenting how great is OC to my friend;) so after 6-7 seconds I tried to click an other directory to test whether the browser is frozen. I was not able to get my data back from the browser, so it looked a bit scary.

Everything is running on a VPS with 2 vcores and 4GB of RAM dedicated to OC. It is not a slow machine and if I think about OC as regular file system, a simple rename should not take so long.

If it cannot be fixed in this OC version, maybe a simple warning telling "do not change directory" could help, or some kind of auto-recovery.

[PVince81]

When you renamed the directory, did you have a sync client that was also connected to this account ?
If yes, then what you experienced is likely to be #13391.

A message "do not change directory" would not help unfortunately because connected clients might also request the state of the folder.

[PVince81]

In the case of file locking, the user might see both folders but they will be locked: it will not be possible to rename them or interact until the transaction is finished.

Now some idea: if we are able to detect that a folder is locked, it could be possible to show it in the web UI. But I see this more as an enhancement than a bug.

So let's do the following:

1. For the issue where files are missing in the web UI, see Data loss on rename of a 49 GB folder #13391
2. For the visual UI issue about showing a "busy" folder, I raised Display spinner for locked folders #16603

And closing this ticket here.