Deleting file within WebUI does not remove database-entries

[xn--nding-jua]

Steps to reproduce

1. have around 1 GB of deleted files within trashbin (around 1000 folders and tens of thousand files)
2. Upload a file to a public-shared folder with Windows-Client
3. Open ownCloud-webinterface
4. Click the Trash-icon on the right side

Expected behaviour

The file should be deleted/moved to trashbin and all entries should be removes from oc_filecache within a short time.

Actual behaviour

The file and its encryption-keys are moved to trashbin, but the entries within the oc_filecache-database are still there. The spinning-wheel spinned for about 10 minutes and I decided to abort by leaving the files-app. Afterwards the file was still in the files-app, but not within the ftp-folder-structure.

I had to use SQL-Tools to remove the old file-entries from oc_filecache. Afterwards everything worked fine again.

Server configuration

Operating system:
Ubuntu 14.04.2 LTS

Web server:
Apache (unknown version)

Database:
SQL 5.4

PHP version:
PHP 5.5

ownCloud version: (see ownCloud admin page)
8.1.0.8

Updated from an older ownCloud or fresh install:
from an older installation (8.0.2)

List of activated apps:
activity: 2.0.1

• bookmarks: 0.4
• calendar: 0.7.2
• contacts: 0.4.0.0
• documents: 0.10.0
• encryption: 1.0.0
• files: 1.1.9
• files_gpxviewer_extended: 1.4
• files_locking:
• files_pdfviewer: 0.7
• files_sharing: 0.6.2
• files_texteditor: 0.4
• files_trashbin: 0.6.3
• files_versions: 1.0.6
• files_videoviewer: 0.1.3
• firstrunwizard: 1.1
• galleryplus: 13
• mail: 0.1.3
• music: 0.3.6
• tasks: 0.6.0
• updater: 0.6
  Disabled:
• external
• files_external
• gallery
• ocsms
• provisioning_api
• templateeditor
• user_external
• user_ldap
• user_webdavauth

The content of config/config.php:

'xxxx', 'passwordsalt' => 'xxxx', 'trusted_domains' => array ( 0 => 'www.xxxx.de', 1 => 'cloud.xxxx.de', 2 => 'xxxx.de', ), 'datadirectory' => '/www/htdocs/xxxx/xxxx/cloud/data', 'dbtype' => 'mysql', 'version' => '8.1.0.8', 'dbname' => 'xxxx', 'dbhost' => 'localhost', 'dbtableprefix' => 'oc_', 'dbuser' => 'xxxx', 'dbpassword' => 'xxxx', 'installed' => true, 'theme' => '', 'maintenance' => false, 'mail_from_address' => 'xxxx', 'mail_smtpmode' => 'php', 'mail_domain' => 'xxxx.de', 'forcessl' => true, 'trashbin_retention_obligation' => 60, 'trashbin_auto_expire' => true, 'loglevel' => 2, 'log_rotate_size' => false, 'logtimezone' => 'Europe/Berlin', 'check_for_working_webdav' => true, 'check_for_working_htaccess' => true, 'xframe_restriction' => false, 'secret' => 'xxxx', 'forceSSLforSubdomains' => true, 'tempdirectory' => '/www/htdocs/xxxx/tmp', 'enable_previews' => true, 'enabledPreviewProviders' => array ( 0 => 'OC\Preview\Image', 1 => 'OC\Preview\MP3', 2 => 'OC\Preview\TXT', 3 => 'OC\Preview\MarkDown', 4 => 'OC\Preview\Illustrator', 5 => 'OC\Preview\Postscript', 6 => 'OC\Preview\Photoshop', 7 => 'OC\Preview\TIFF', ), 'singleuser' => false, ); **Are you using external storage, if yes which one:** local/smb/sftp/... no **Are you using encryption:** yes/no yes **Are you using an external user-backend, if yes which one:** LDAP/ActiveDirectory/Webdav/... no ### Client configuration ownCloud Client 2.0.0 **Browser:** Firefox 40 **Operating system:** Windows 7 64-Bit

[karlitschek]

@schiesbn anu idea?

[PVince81]

@xn--nding-jua were the stray entries in oc_filecache the ones from the encryption keys ? Were they still pointing at the original folder instead of being changed to point to "files_trashbin" ?

[xn--nding-jua]

@PVince81 no, all file-related entries were in oc_filecache: file itself and key-entries. Obviously I've aborted the database commands as I've cancelled the operation. So this seems not to be the problem, but the long operation on deleting so that someone will abort it.

[PVince81]

@xn--nding-jua do the path of these entries contains a section with "filenameXXXXXX.part" ?
Could be a duplicate of #17997.

[xn--nding-jua]

@PVince81 no, all original entries where still there. No additional entries (e.g. part-files) have been created. As I've written on my last post here, it looks like I've aborted the delete-progress, so that the oc_filecache has not been changed (observed in WebUI and phpmyadmin) but the files itself have been moved already (observed by ftp).

My deleting-retention of the trashbin is set to 60 days, because I want to have two backup-cycles. So the amount of file within the trashbin is quite large.

The reason why I've opened this issue is, that someone without sql-knowledge is not able to remove the orphaned entries and will have some ghost-files within the WebUI (and maybe the Webdav connection).

I think it could be solved if the performance of the delete-process can be increased, or some feedback is given to the user, what is happening on processing the delete-operation (maybe a progressbar?). At the moment we are looking at the spinning-wheel for minutes without a further feedback. I know: easy to write but hard to change. Obviously this can be lead back to my sharing-host - the performance on DB-operations seems not to be the best.

[rgugliel]

Same problem here,

Server: Ubuntu 14.04.3

Owncloud:
8.2.1.4 with sqlite3
No encryption

Client: Firefox on Linux Mint.

[PVince81]

@rgugliel mind providing more details about your database entries ? Just to gather more clues.
Thanks.

[rgugliel]

@PVince81 : Sorry for this maybe stupid question but what kind of details?

[rgugliel]

Here was the situation:
I had inside the sync folder a folder "code" and inside this folder another folder called "pcre33". This pcre33 was the problem: it was not on my machine nor on the filesystem in the server but keep appearing in the webapp. I tried to rename it (error: cannot rename it since the folder was deleted) and delete it; without success.

Since it completely broke the sync of the parent folder I had to delete the parent folder "code" and start again.

[PVince81]

Orphaned entries will now be removed as per #24499

[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.