It's impossible to delete file while it's being synced

[arabesc]

Steps to reproduce

1. use desktop ownCloud client app, setup sync folder;
2. upload some large file in the ownCloud web interface/Files menu;
3. as soon as sync download has started try to delete uploaded file in the web interface/Files menu.

Expected behaviour

The file has been deleted. The sync has been interrupted.

Actual behaviour

It's impossible to delete file while it's being synced.
There is message: "Could not delete: "

Server configuration

Operating system:
FreeBSD 10.2

Web server:
nginx-1.8.0

Database:
MariaDB-10.0.23

PHP version:
PHP-5.6.16

ownCloud version: (see ownCloud admin page)
ownCloud-8.2.2

Updated from an older ownCloud or fresh install:
Fresh install.

List of activated apps:

Enabled:
  - activity: 2.1.3
  - calendar: 0.8.1
  - contacts: 0.5.0.0
  - files: 1.2.0
  - files_external: 0.3.0
  - files_pdfviewer: 0.7
  - files_sharing: 0.7.0
  - files_texteditor: 2.0
  - files_trashbin: 0.7.0
  - files_versions: 1.1.0
  - files_videoviewer: 0.1.3
  - firstrunwizard: 1.1
  - gallery: 14.2.0
  - notifications: 0.1.0
  - provisioning_api: 0.3.0
  - templateeditor: 0.1
  - updater: 0.6
Disabled:
  - encryption
  - external
  - user_external
  - user_ldap

The content of config/config.php:

{
    "system": {
        "instanceid": "************",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "example.com"
        ],
        "datadirectory": "/mnt/storage/owncloud/data",
        "overwrite.cli.url": "https://example.com/owncloud",
        "dbtype": "mysql",
        "version": "8.2.2.2",
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "logtimezone": "Europe/Moscow",
        "installed": true,
        "activity_expire_days": 90,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "allow_user_to_change_display_name": true,
        "check_for_working_webdav": true,
        "check_for_working_htaccess": true,
        "loglevel": 0,
        "cron_log": true,
        "assetdirectory": "/usr/local/www/owncloud",
        "asset-pipeline.enabled": true,
        "maintenance": false,
        "singleuser": false,
        "filesystem_check_changes": 1,
        "debug": false
    }
}

Are you using external storage, if yes which one: local/smb/sftp/...
NO

Are you using encryption: yes/no
NO

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
NO

Client configuration

Browser:
Firefox-43.0.4

Operating system:
Mac OS X 10.11.2

[RobinMcCorkell]

@icewind1991 Locking doing silly things? Is there any way we can forcefully terminate downloads of files if they are about to be deleted, or is that a Very Bad Thing ™️ ?

[rullzer]

Well this is exactly why we have file locking. To make sure that only 1 instance at a time can do destructive behavour.

We make sure all the locks are in place before we start doing stuff and release after. Thus terminating will probably be hell to do.

[JohannesKleine]

The same thing should happend, if an formerly offline client starts syncing, only few second before I have started to delete files. To save bandwidth and give the owner of files the possibility to correct things, maybe he uploaded the wrong file. So I appreciate giving "delete" higher priority than "sync".

[PVince81]

This is expected behavior due to file locking.

@icewind1991 what do you think of the suggestion regarding priority ?

[rullzer]

It is not a matter of priority it is a matter of independent processes. If 1 process in chaning the file (and has it locked) and another php process wants to delete we have no way of signaling the chaning process to stop.

A lot of operating systems also do not allow this. And I do not really see a way to cleanly signal other processes in a clean way right now...

[icewind1991]

I agree that this is expected behavior and not something we can solve without a lot more work in locking

[PVince81]

The only thing that could be done somehow within the current architecture is to add a small waiting delay if a file is locked. The delay must still have a timeout after a few seconds.

The old file locking had something like this: https://github.com/owncloud/files_locking/blob/master/lib/lock.php#L105

This could increase the change of a deletion to succeed. The problem here though is that the PHP request might time out, and then either get killed (when using php5-fpm) or it will continue but the client will believe that it failed.

[PVince81]

@DeepDiver1975 @karlitschek see previous comment about lock wait with usleep instead of bailing out directly. Could help a bit.

[PVince81]

Not sure about severity. So far this is by design, but it would be a nice improvement that could reduce the likeliness of a bad UX in the case someone wants to delete locked files in the web UI.

[karlitschek]

Agreed. Good idea @PVince81

[PVince81]

Since we're past feature freeze, adding this logic right now would be a bit risky.
I suggest to look into this in 9.1.

We also might want to evaluate whether the waiting should be done for all operations or only a few like deletions.

@cmonteroluque

[arabesc]

While it's impossible to delete this file immediately it should be possible to rename/move it. Then why do not move this file to an invisible folder for trash with some unique name?

[PVince81]

Rename is not possible either. This is unlike the linux filesystem where a file being written to can be moved while another process still has it open. This won't work with external storages.

Also the file cache and other processes might have trouble too if we're moving the file in the middle of an operation.

[PVince81]

Somewhat related to async file operations: #24509

[PVince81]

Another possible solution: #17016
I'll close this ticket in favor of #17016

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.