New files (folders) first uploaded then erased!!

[maddhin]

I have the following problem (using 1.3.0 and betas / clients before, this is not 1.3.0 specific, Win7 64bit): after initial sync, I realized missing files, I copied them again from a backup back to my laptop into the owncloud folder. Then it took forever to sync it with the cloud (NAS in same network, about 2 GB data which should normally sync in no time). 2 days later, when most(!) of the files were on the server, owncloud / client started to erase them again - about 600 files, also took a very long time to do so (high load on NAS / server). Ridiculously it erases only the files on the laptop but not the folders. Hence the folder structure is still intact but no files inside.

One might want to say the worst bug a syncing client can have...

I get the following in the log:

06-26 13:05:46:073 _csync_remove_dir: dir: C:/Users/XYZ, command: rmdir, error: Operation not permitted 06-26 13:05:47:385 oc_module: Neon error code was 1

This way it cycles through the dirs and removes the files that have been uploaded before. Strangely it leaves other files and dirs alone. AFAIK this whole thing is only happening for certain dirs. I have a particular dir which, after the initial sync from laptop to cloud, had about half the dirs missing. So I copied the missing dirs from backup and the upload/deletion cycle is starting...

Anybody any idea what could cause this?

[danimo]

Can you give me the rest of the log as well? This line already looks interesting, I need more context.

[maddhin]

That would be the log automatically generated:

06-27 16:47:41:295 "################## ownCloud de_DE (de_DE) 1.3.0" 06-27 16:47:41:863 * Setup folders from "C:\Users\User2\AppData\Local\ownCloud/folders" 06-27 16:47:41:863 ` -> setting up: "Dokumente" 06-27 16:47:41:864 -> file path: "C:/Users/User2/AppData/Local/ownCloud/folders/Dokumente" 06-27 16:47:41:864 Returning configured owncloud url: "https://serverURL:8081/owncloud/remote.php/webdav/" 06-27 16:47:41:864 setting remote poll timer interval to 28349 msec for folder "Dokumente" 06-27 16:47:41:865 * Pending events for "C:/Users/User2/ownCloud" will be processed after events stop for 1000 milliseconds ( "17:04:21" ). 0 events until now ) 06-27 16:47:41:865 ==> returning exclude file path: "C:/Program Files (x86)/ownCloud/sync-exclude.lst" 06-27 16:47:41:866 Checked local path ok 06-27 16:47:41:866 \ ownCloud folder using watcher *** 06-27 16:47:41:868 ==> returning exclude file path: "C:/Program Files (x86)/ownCloud/sync-exclude.lst" 06-27 16:47:41:868 ==== added CSync exclude List: "C:/Program Files (x86)/ownCloud/sync-exclude.lst" 06-27 16:47:41:868 csync_exclude_load: Loading exclude file: C:/Program Files (x86)/ownCloud/sync-exclude.lst 06-27 16:47:41:868 csync_excludeload: Adding entry: .filepart 06-27 16:47:41:868 csync_exclude_load: Adding entry: ~ 06-27 16:47:41:869 csync_exclude_load: Adding entry: .bak 06-27 16:47:41:869 csync_exclude_load: Adding entry: .part 06-27 16:47:41:869 csync_exclude_load: Adding entry: .crdownload 06-27 16:47:41:869 csync_excludeload: Adding entry: *.unison 06-27 16:47:41:869 csync_exclude_load: Adding entry: _csynctimedif.ctmp 06-27 16:47:41:869 csync_excludeload: Adding entry: ..sw? 06-27 16:47:41:869 csync_excludeload: Adding entry: .._sw? 06-27 16:47:41:870 csync_exclude_load: Adding entry: .DS_Store 06-27 16:47:41:870 csync_exclude_load: Adding entry: .ds_store 06-27 16:47:41:870 csync_exclude_load: Adding entry: desktop.ini 06-27 16:47:41:870 csync_exclude_load: Adding entry: Thumbs.db 06-27 16:47:41:870 csync_exclude_load: Adding entry: .kate-swp 06-27 16:47:41:870 csync_exclude_load: Adding entry: .aux 06-27 16:47:41:870 csync_exclude_load: Adding entry: .nav 06-27 16:47:41:871 csync_exclude_load: Adding entry: .out 06-27 16:47:41:871 csync_exclude_load: Adding entry: .toc 06-27 16:47:41:871 csync_exclude_load: Adding entry: conflict- 06-27 16:47:41:871 csync_exclude_load: Adding entry: .TemporaryItems 06-27 16:47:41:871 csync_exclude_load: Adding entry: .Trashes 06-27 16:47:41:871 csync_exclude_load: Adding entry: .DocumentRevisions-V100 06-27 16:47:41:872 csync_exclude_load: Adding entry: .fseventd 06-27 16:47:41:872 csync_exclude_load: Adding entry: .apdisk 06-27 16:47:41:872 csync_exclude_load: Adding entry: .htaccess 06-27 16:47:41:872 csync_exclude_load: Adding entry: Icon\r 06-27 16:47:41:872 csync_exclude_load: Adding entry: ~$ 06-27 16:47:41:872 csync_exclude_load: Adding entry: .~lock. 06-27 16:47:41:873 csync_config_load: Config: max_depth = 50 06-27 16:47:41:873 csync_config_load: Config: max_time_difference = 10 06-27 16:47:41:874 csync_config_load: Config: sync_symbolic_links = 0 06-27 16:47:41:874 csync_config_load: Config: timeout = 0 06-27 16:47:41:874 csync_exclude_load: Loading exclude file: C:\Users\User2\AppData\Local\ownCloud//ocsync_exclude.conf 06-27 16:47:41:874 csync_init: Could not load C:\Users\User2\AppData\Local\ownCloud//ocsync_exclude.conf - No such file or directory 06-27 16:47:41:874 csync_init: Journal: C:/Users/User2/ownCloud/.csync_journal.db 06-27 16:47:41:920 csync_vio_init: Win32: changing current working dir to C:\Program Files (x86)\ownCloud 06-27 16:47:41:921 csync_vio_init: Win32: changing current working dir to C:\Program Files (x86)\ownCloud 06-27 16:47:41:924 csync_vio_init: capabilities: atomar copy support: yes 06-27 16:47:41:924 csync_vio_init: capabilities: post copy stat: no 06-27 16:47:41:925 csync_vio_init: capabilities: time sync required: no 06-27 16:47:41:925 csync_vio_init: capabilities: unix extensions: 0 06-27 16:47:41:925 csync_vio_init: capabilities: use send_file: yes 06-27 16:47:41:925 csync_init: Module does not need time synchronization. 06-27 16:47:41:925 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:943 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:943 Passing NO proxy to csync for "https://serverURL:8081/owncloud/" 06-27 16:47:41:944 Adding folder to Folder Map Mirall::ownCloudFolder(0x4bd42e0) 06-27 16:47:41:944 Check status.php from statusdialog. 06-27 16:47:41:944 Get Request to "status.php" 06-27 16:47:41:944 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:944 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:945 Setting up host header: "serverURL" 06-27 16:47:41:945 Folder in overallStatus Message: Mirall::ownCloudFolder(0x4bd42e0) with name "Dokumente" 06-27 16:47:41:947 Sync state changed for folder "Dokumente" : "Not yet Started" 06-27 16:47:41:947 Folder: Mirall::ownCloudFolder(0x4bd42e0) 06-27 16:47:41:947 Returning configured owncloud url: "https://serverURL:8081/owncloud/remote.php/webdav/" 06-27 16:47:41:948 Check status.php from statusdialog. 06-27 16:47:41:948 Get Request to "status.php" 06-27 16:47:41:948 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:949 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:949 Setting up host header: "serverURL" 06-27 16:47:41:951 Network Location: "" 06-27 16:47:42:010 \ Mirall shutdown

[maddhin]

here from what I got from the logwindow (I erased most redundent stuff as it has been A LOT)

first, csync_merge_algorithm_visitor goes on for thousands of files:

06-27 16:45:47:797 _csync_merge_algorithm_visitor: INSTRUCTION_NONE file: Company/Countrya/Comp/Homepage COUNTRYA/Kopien Comp homepage/maintenance-Dateien/headseg_202.gif 06-27 16:45:47:797 _csync_merge_algorithm_visitor: INSTRUCTION_NONE file: Temp/Neuer Ordner/90005568261.pdf 06-27 16:45:47:797 _csync_merge_algorithm_visitor: INSTRUCTION_NONE file: Company/Countrya/Comp/Homepage COUNTRYA/Kopien Comp homepage/routine-Dateien/headseg_104.gif

but then:

06-27 16:45:47:797 csync_reconcile: Reconciliation for remote replica took 0.29 seconds visiting 10617 files. 06-27 16:46:31:336 * csync thread started 06-27 16:46:31:337 Returning configured owncloud url: "https://serverURL:8081/owncloud/remote.php/webdav/" 06-27 16:46:31:338 Check status.php from statusdialog. 06-27 16:46:31:338 Get Request to "status.php" 06-27 16:46:31:339 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:46:31:339 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:46:31:339 Setting up host header: "serverURL" 06-27 16:46:31:341 Folder in overallStatus Message: Mirall::ownCloudFolder(0x497a7a8) with name "Dokumente" 06-27 16:46:31:342 Sync state changed for folder "Dokumente" : "Sync Running" 06-27 16:45:47:813 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-03-26-1253467248_04-EVN.pdf, command: unlink, error: Permission denied 06-27 16:45:47:813 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-11-23-1346767663_04-EVN.pdf, command: unlink, error: Permission denied 06-27 16:45:47:814 _csync_push_file: continuation: 1 -1453106674 06-27 16:45:47:814 csync_vio_stat: Win32: STAT-inode for C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Tunel_2_wgs84_Zone38.jpg: 129508 06-27 16:45:47:814 _csync_push_file: Remote repository atomar push enabled for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Tunel_2_wgs84_Zone38.jpg (0). 06-27 16:45:47:814 oc_module: => open called for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Tunel_2_wgs84_Zone38.jpg 06-27 16:45:47:814 oc_module: Stating directory ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs 06-27 16:45:47:814 oc_module: owncloud_stat ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs called 06-27 16:45:48:278 oc_module: Simple propfind result code 207. 06-27 16:45:48:278 oc_module: => Errno after fetch resource list for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs: 0 06-27 16:45:48:278 oc_module: Working on file Yyy docs 06-27 16:45:48:278 oc_module: STAT result from propfind: Yyy docs, mtime: 1372322199 06-27 16:45:48:278 oc_module: Directory of file to open exists. 06-27 16:45:48:278 oc_module: PUT request on /owncloud/remote.php/webdav/Dokumente/COMPANY2/Country%20Tunnel/Yyy%20docs/Tunel_2_wgs84_Zone38.jpg! 06-27 16:45:48:278 oc_module: Sendfile handling request type PUT. 06-27 16:45:48:278 oc_module: Existing chunk info 1 -1453106674 06-27 16:46:15:565 _csync_push_file: file: C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Tunel_2_wgs84_Zone38.jpg, command: sendfile, error: No error from errno 0 06-27 16:46:15:565 _csync_push_file: remember chunk: 0 (transfer id -1453106674 ) 06-27 16:46:15:565 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-09-25-1326017840_04-EVN.pdf, command: unlink, error: Permission denied 06-27 16:46:15:566 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-02-24-1241754936_04-RG.pdf, command: unlink, error: Permission denied 06-27 16:46:15:566 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-01-24-1230024381_04-RG.pdf, command: unlink, error: Permission denied 06-27 16:46:15:566 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-02-24-1241754936_04-EVN.pdf, command: unlink, error: Permission denied 06-27 16:46:15:566 _csync_push_file: continuation: 1 -1448232641 06-27 16:46:15:567 csync_vio_stat: Win32: STAT-inode for C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Tunel_3_wgs84_Zone38.jpg: 129582 06-27 16:46:15:567 _csync_push_file: Remote repository atomar push enabled for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Tunel_3_wgs84_Zone38.jpg (0). 06-27 16:46:15:567 oc_module: => open called for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Tunel_3_wgs84_Zone38.jpg 06-27 16:46:15:567 oc_module: Stating directory ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs 06-27 16:46:15:567 oc_module: Dir ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs is there, we know it already. 06-27 16:46:15:567 oc_module: PUT request on /owncloud/remote.php/webdav/Dokumente/COMPANY2/Country%20Tunnel/Yyy%20docs/Tunel_3_wgs84_Zone38.jpg! 06-27 16:46:15:567 oc_module: Sendfile handling request type PUT. 06-27 16:46:15:567 oc_module: Existing chunk info 1 -1448232641 06-27 16:46:34:464 status.php returns: "{"installed":"true","version":"5.0.12","versionstring":"5.0.7","edition":""}" 0 Reply: QNetworkReplyImpl(0xa1a8010) 06-27 16:46:34:465 #-------# oC found on "https://serverURL:8081/owncloud" 06-27 16:46:44:514 _csync_push_file: file: C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Tunel_3_wgs84_Zone38.jpg, command: sendfile, error: No error from errno 0 06-27 16:46:44:514 _csync_push_file: remember chunk: 0 (transfer id -1448232641 ) 06-27 16:46:44:514 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-07-25-1301746668_04-RG.pdf, command: unlink, error: Permission denied 06-27 16:46:44:515 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-01-24-1230024381_04-EVN.pdf, command: unlink, error: Permission denied 06-27 16:46:44:515 _csync_push_file: continuation: 1 -1446550890 06-27 16:46:44:515 csync_vio_stat: Win32: STAT-inode for C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Geology.jpg: 129690 06-27 16:46:44:515 _csync_push_file: Remote repository atomar push enabled for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Geology.jpg (0). 06-27 16:46:44:515 oc_module: => open called for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Geology.jpg 06-27 16:46:44:515 oc_module: Stating directory ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs 06-27 16:46:44:515 oc_module: Dir ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs is there, we know it already. 06-27 16:46:44:515 oc_module: PUT request on /owncloud/remote.php/webdav/Dokumente/COMPANY2/Country%20Tunnel/Yyy%20docs/Geology.jpg! 06-27 16:46:44:515 oc_module: Sendfile handling request type PUT. 06-27 16:46:44:515 oc_module: Existing chunk info 1 -1446550890 06-27 16:47:10:592 _csync_push_file: file: C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Geology.jpg, command: sendfile, error: No error from errno 0 06-27 16:47:10:593 _csync_push_file: remember chunk: 0 (transfer id -1446550890 ) 06-27 16:47:10:593 _csync_push_file: continuation: 1 -1445054665 06-27 16:47:10:593 csync_vio_stat: Win32: STAT-inode for C:/Users/User/ownCloud/COMPANY2/Country Tunnel/Yyy docs/Tunel_1_wgs84_Zone38.jpg: 129722 06-27 16:47:10:593 _csync_push_file: Remote repository atomar push enabled for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Tunel_1_wgs84_Zone38.jpg (0). 06-27 16:47:10:593 oc_module: => open called for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs/Tunel_1_wgs84_Zone38.jpg 06-27 16:47:10:593 oc_module: Stating directory ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs 06-27 16:47:10:593 oc_module: Dir ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/COMPANY2/Country Tunnel/Yyy docs is there, we know it already. 06-27 16:47:10:593 oc_module: PUT request on /owncloud/remote.php/webdav/Dokumente/COMPANY2/Country%20Tunnel/Yyy%20docs/Tunel_1_wgs84_Zone38.jpg! 06-27 16:47:10:593 oc_module: Sendfile handling request type PUT. 06-27 16:47:10:593 oc_module: Existing chunk info 1 -1445054665 06-27 16:47:41:965 "################## ownCloud de_DE (de_DE) 1.3.0" 06-27 16:47:41:966 #============# Status dialog starting #=============# 06-27 16:47:41:967 Folder: Mirall::ownCloudFolder(0x497a7a8) 06-27 16:47:41:968 Returning configured owncloud url: "https://serverURL:8081/owncloud/remote.php/webdav/" 06-27 16:47:41:969 Check status.php from statusdialog. 06-27 16:47:41:970 Get Request to "status.php" 06-27 16:47:41:970 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:971 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:41:972 Setting up host header: "serverURL" 06-27 16:47:42:015 Check status.php from statusdialog. 06-27 16:47:42:016 Get Request to "status.php" 06-27 16:47:42:017 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:42:017 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:42:018 Setting up host header: "serverURL" 06-27 16:47:42:020 Check status.php from statusdialog. 06-27 16:47:42:021 Get Request to "status.php" 06-27 16:47:42:022 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:42:026 Returning configured owncloud url: "https://serverURL:8081/owncloud/" 06-27 16:47:42:027 Setting up host header: "serverURL" 06-27 16:47:44:328 SSL-Warnings happened for url "https://serverURL:8081/owncloud/status.php" 06-27 16:47:44:329 Certs are already known and trusted, Warnings are not valid. 06-27 16:47:44:637 SSL-Warnings happened for url "https://serverURL:8081/owncloud/status.php" 06-27 16:47:44:637 Certs are already known and trusted, Warnings are not valid. 06-27 16:47:45:890 oc_module: Simple propfind result code 207. 06-27 16:47:45:890 oc_module: => Errno after fetch resource list for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/Company/Abc/Comp4: 0 06-27 16:47:45:890 oc_module: Working on file Comp4 06-27 16:47:45:890 oc_module: STAT result from propfind: Comp4, mtime: 1168006698 06-27 16:47:45:890 _csync_new_dir: dir: ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/Company/Abc/Comp4/Bj Int'l Hotel, command: mkdirs, error: Not a directory 06-27 16:47:47:593 oc_module: Neon error code was 1 06-27 16:47:47:593 _csync_remove_dir: dir: C:/Users/User/ownCloud/COMPANY2/Country BawaNur/Contract, command: rmdir, error: Operation not permitted 06-27 16:47:47:593 oc_module: owncloud_stat ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/Company/Presentations called 06-27 16:47:47:666 status.php returns: "{"installed":"true","version":"5.0.12","versionstring":"5.0.7","edition":""}" 0 Reply: QNetworkReplyImpl(0x743c7b8) 06-27 16:47:47:667 #-------# oC found on "https://serverURL:8081/owncloud" 06-27 16:47:52:978 status.php returns: "{"installed":"true","version":"5.0.12","versionstring":"5.0.7","edition":""}" 0 Reply: QNetworkReplyImpl(0xc21af80) 06-27 16:47:53:147 oc_module: Simple propfind result code 207. 06-27 16:47:53:147 oc_module: => Errno after fetch resource list for ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/Company/Presentations: 0 06-27 16:47:53:147 oc_module: Working on file Presentations 06-27 16:47:53:147 oc_module: STAT result from propfind: Presentations, mtime: 1025643042 06-27 16:47:53:147 _csync_new_dir: dir: ownclouds://serverURL:8081/owncloud/remote.php/webdav/Dokumente/Company/Presentations/Comp Video Transfered, command: mkdirs, error: Not a directory 06-27 16:47:53:267 status.php returns: "{"installed":"true","version":"5.0.12","versionstring":"5.0.7","edition":""}" 0 Reply: QNetworkReplyImpl(0x743c058) 06-27 16:47:56:458 oc_module: Neon error code was 1 06-27 16:47:56:458 _csync_remove_dir: dir: C:/Users/User/ownCloud/Company/Abc/CDE/??/????/????? 6.09 2006-6-14 17-25-37/Category/????/???, command: rmdir, error: Operation not permitted 06-27 16:47:59:854 oc_module: Neon error code was 1 06-27 16:47:59:854 _csync_remove_dir: dir: C:/Users/User/ownCloud/Company/Abc/CDE/??/??/Dieter Petersin, command: rmdir, error: Operation not permitted 06-27 16:48:02:042 oc_module: Neon error code was 1

from then on it is basically only "Neon error code was 1" and occasionally "Simple propfind result code 207"...

I hope that helps.

[dragotin]

The logfile shows permission errors on the local file system, for example 06-27 16:46:44:514 _csync_remove_file: file: C:/Users/User/ownCloud/Company/D Ltd. & Co KG/BF/O2 Xy/2012-07-25-1301746668_04-RG.pdf, command: unlink, error: Permission denied

[maddhin]

Can I do something to fix these permission errors? It's a Win7 (64bit), single user machine, not sure what can be done with permissions...

[daarong]

Yesterday I installed "Server 5" (latest advertised).. and installed the latest client side on Win7x64. After general instability, unreliability, performance issues, etc... I'm now digging through these github issues and seeing this type of thing! SCARY.

I'm definitely going to have to shelve ownCloud for another year or two. I hope you guys can make this work. It's probably over 99% ready for prime time.

Related to this issue of unexpected deletion - there should definitely be a client option to never delete anything from the client. No doubt many are like me and just want ownCloud as a PC insurance plan, with the added perk that you can fetch files and drop in new ones remotely.

[pcreadycl]

i have same problem, any ideas?

[maddhin]

It is scary when you look at it but if your data disappears and you don't even know WHAT owncloud is erasing (the only thing I always get is the little pop-up saying 'owncloud has erased 343 files'!!!!) it is a disaster and should be unthinkable for such a solution. Although I love the project and everybody does an amazing job but, sorry, IMHO it is irresponsible to let the software go beyond BETA with such issues.

[vladreamer]

I have same issue with OwnCloud server 5.0.7 on Linux CentOS6.4 x64 and Mac OS X desktop clients v. 1.3.0 Files disappear from user's folders without any reason and without notifications. It makes users very angry and frustrate about this software.

Is this issue presents only in free version? Will it be possible to avoid this problem if we pay for license?

[pcreadycl]

this issues is for wrong sync "client to server".

files are created in the client pc, but as they are synchronized with the server at startup again apparently the master copy is the server and not your computer, so empty folders and delete all the files created.

I think it is a very serious problem, which I have already referred the post:

https://forum.owncloud.org/viewtopic.php?f=14&t=13120

But the support response was that the software does not work collaboratively, yet do not see the problem that is being presented with this "feature" disabled or absent.

Owncloud is a very handy tool for those who are users of this but support should be more flexible so that the public and users need.

[maddhin]

@pcreadycl : thanks for bringing this up, it seems there are much more issues than I thought. Collaboration is no major issue to me, but using Owncloud to sync several PCs you are pointing out another scary scenario. Looks like I need to double-check every file I change now:(((

One hint: there is a syncing software called syncing.net (www.syncing.net). I have no relations with them whatsoever but used it for many years until they struggled and sold the company and the new owner wants the old clients to buy the software again (-> no way!). BUT their client supports P2P and solved all these issues billiantly. IMHO their client together with Owncloud as server would be an amazing product kicking out all cloud and sycning solutions in the market. Just saying...

[pcreadycl]

maddhin: I do not really want to work with a solution that is based on Windows and private code. Owncloud is perfect for what I need because it is open source and is based linux systems to operate.

I think it's important that you take this request as a priority, not the rest of the stuff but at least give us a date of settlement of weeks or months if necessary.

In my company I am interested in integrating owncloud to all my clients, but to do so I require that this works in this respect equal to dropbox.

Dropbox is an option to platform but the costs of operation and latency of their servers in USA we are concerned to implement a final, however if we can put local servers, or at least add these to our data, it would be the perfect solution .

I will not impose on dispocision makers, administrators, moderators or testers.

I can support them in the implementation of this system here in Chile, as a reseller or parnert.

Hopefully this can be answered shortly by some owncloud developer. Thank you!

[maddhin]

Yes, I also dislike private code but maybe one of the developer can contact them and see if there is any way they can collaborate. I believe it is worth a try as this could push this project and could save months or even years of development. I also think the syncing.net have a viable interest in collaboration. Anyway, won't hurt to ask...

I entirely agree on "take this request as priority" though :+1: Without a fix, owncloud is pretty useless to me :(

[pcreadycl]

The scenario is:

In this scenario there will never users working offline.

I have a local server (Ubuntu 12.04 LTS) in the office which stores all the information and shares it with Samba4, that server users connect through the intranet and work on the server.

It occurred to me that if I install a secondary server in the same office and install owncloud 5.0.7 (Ubuntu 12.04 LTS) could create my own cloud to share files with clients.

But it also occurred to me that could store all files on a server with owncloud.

How I would do?

In the storage server office owncloud client install (. Deb) and synchronize the folders that I have shared with samba, then I am a mirror copy from a server to another server.

Synchronize everything perfect and users can work on the server without problems and updated files are copied to the new server and I can manage versions and restore them if necessary.

The problem starts with the new files and folders. When you create a new folder on the server locally almanacenamiento or through the intranet teams, the folder is created on the server, but the client does not understand the owncloud synchronized with the server and delete it the next synchronization with all its contents.

When working with Samba4 platform and have the "oplock" assets 2 users will never be able to work on the same file, so that collaborative or concurrent mode is not what I need.

As you can update the client or recompiled to any change is detected in the system is uploaded to the server owncloud?

I think the problem is not owncloud platform, if the client does not recognize changes in file storage server, then do not think the problem is greater, today I worked with a python development that integrates the kernel system and is compatible with all linux platforms. This script is able to detect all file changes recursively system to detect a change and run a line or several lines of command to the file or files.

So if the sync off layers to detect file changes as does this script would be solved this problem, the issue is that I am not a developer, I am network engineer.

The script is very simple and basic but effective and what matters in the systems is the effectiveness of this once implentado. It is very similiar to inotify, but the advantage is that it can work with subfolders, which does inotify.

This is the URL: http://www.splitbrain.org/blog/2011-01/07-watcher_a_recursive_incron_alternative

I hope we can figure this out friends, if I can help with anything I will.

[karlitschek]

We are very sorry for the trouble. We are looking into the issue if you help us to debug and reproduce it. Thanks a lot for the understanding.

[pcreadycl]

I found a solution to this problem ..!

The solution is not the most efficient, but it shows that the problem is the software platform synchronization owncloud.

Tomorrow publishes my results and the scheme used in the solution.

Owncloud hope developers take this into account and in the next beta version synchronization software can make changes to make it work properly.

Thank you all for your time.

Url: http://forum.owncloud.org/viewtopic.php?f=14&t=13120

[dragotin]

Lets please focus on @maddhin s problem first. @maddhin, do you still have the full log of one sync run? The log you posted above shows that the client tries to remove stuff, but not, why it came to the conclusion to do that. That is in the update phase of the csync run which we would see in the whole log. Please use either gist or mail directly to me.

A couple of other questions:

• do you have the client dir on a nfs, samba or windows offline folders directory for sync?
• do you have special backends configured on the ownCloud server?
• any idea why you have permission denied problems locally? Thanks for answering.

[maddhin]

I had also the feeling that there was something missing but that was the whole log I got. I will try to make a new sync but work keeps me v busy these days:(

Other questions: 3x no or not that I would know of. I simply installed owncloud on my Qnap NAS, added a folder on my HDD and added the files into that folder and owncloud synced. But even the first sync did not run smooth and there were files and folders missing (= erased!) in the client folder on laptop HDD. This is how I found this problem...

The folder on the NAS is - I'd guess - some NFS or something folder. But also nothing special. I store the data in a separated folder and not in the /Web dir. But that should make no difference.

[pcreadycl]

@maddhin Please explain to me in detail what your problem is with a scenario of connections between devices and the configuration of these in order to help you, I think your problem is very similar to mine, that the folders are deleted.

[maddhin]

@pcreadycl I'm not sure if I completely understand your question. Let me try: when I put new files in my owncloud folder on my Win7 x64, they sync as they should (which seems terribly slow though) and after the sync is done, it starts (randomly?) erasing files and folders. It seems, it only erases files and leaves the main folders. That is all I know - I synced all my files (like 10.000 and tons of folders), so I have a hard time to track what is erased and what not. But once in a while I find files missing. So, the erasing is not limited to the "new" folder.

Another device / client (Win7 x32) doesn't seem to do anything. It neither syncs the new files (while they are e.g. still upload from the other client) nor erases them. It seems this client has no idea what is going on. The syncing seems to work with "a few" files though. Also the initial sync mirrored all files in the cloud.

It appears that the server "forgets" or "not indexes" the newly added files so they doesn't seem to exist for the server and then tells the client to erase them on Win7.

IMHO some "communication" issue between server/client while syncing/uploading.

[dragotin]

@maddhin can you access the http server error log on the QNAP and check that for us?

[maddhin]

checked - it is a blank empty file...!

In the access and ssl_request logs I can see the owncloud access though. No obvious connection errors then?

[danimo]

@maddhin If you installed it on your QNAP, there is no NFS involved. The interesting questions here are: How did you install it (is there a pre-made package for it?) and are you accessing the same data by other means, e.g. NFS, Samba?

[maddhin]

There was (is?) no QPKG package to install it conveniently on QNAP. So I followed some good instructions (http://www.welzels.de/blog/2012/10/die-eigene-wolke-owncloud-auf-qnap-nas/) to install Version 4 first. As a few weeks later Version 5 came out, I did erase version 4 and installed version 5. The install went basically smooth, I did have some permission issues in the end but IMHO that were minor issues and more caused by my (very) limited Linux capabilities…

I could not automatically (via webGUI) update from v5.0.6 (or 5.0.5) to 5.0.7 as always “cannot create backup”-error or similar came up. I had to do update it manually and had to “do something” with the permissions for the /Web dir (I think). Sorry, I cannot recall what exactly finally made it update as I am – in Linux! ☺ - sometimes not understanding everything I am doing ☺ But I think the manual update just went through.

The owncloud data is on a separated /share/owncloud folder and the executable on /Web. I do not access the data with anything else but I do make rsnapshot backups every 2 hours. But that should not affect anything.

One thing is maybe worth mentioning: I was trying to figure out what cause the data loss and saw that if I log in via webgui with my username it made a difference whether I use maddhin or Maddhin with capital letters. If the “real” folder was “Maddhin” and I logged in with maddhin, owncloud created an empty “maddhin” folder in parallel to “Maddhin”. No idea if this is related, but 5.0.7 seem to have fixed this.

[dragotin]

@maddhin so it would be good if you could verify if this problem still happens with 5.0.7 or 5.0.8 which was recently released. The last paragraph of your last comment sounds scary...

[maddhin]

Yes, there entire scenario / problem happens under 5.0.7 with 1.3.0 client.

Will install 5.0.8 and report back.

Last paragraph: "scary" is polite. I was more think along the classic 3 letter starting with a W, ending with a F and a T in the middle... Funnily - I checked - there was really only on user in the DB... Anyway, it seems fixed...

[dragotin]

@maddhin can you let us know what the following SQL statement gives you, done on the servers (!) database:

select distinct user from oc_fscache;

[maddhin]

@dragotin uh, could you let me know where I should run this exactly? My Linux skills are pretty much following instructions / copy & paste... :)

[maddhin]

I'm trying to update to 5.0.8 but the automatic (via GUI button) update fails "cannot create backup".

When manually trying I get the following:

[~] # rsync -a /share/MD0_DATA/Web/owncloud owncloud-bkpdate +"%Ym%d"/ rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) rsync: write failed on "/root/owncloud-bkp2013m13/owncloud/backup/5.0.12-6e96d0df/3rdparty/fontawesome/font/fontawesome-webfont.svg": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7] rsync: connection unexpectedly closed (750 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]

The only thing I can understand is "No space left on device" - which is definetely not the case.

I have no idea if this is related to the issues at hand but maybe?

I'm trying the update without backup now.

[maddhin]

OK, after correcting a typo and specifiying the backup folder properly:

rsync -a /share/MD0_DATA/Web/owncloud /share/MD0_DATA/Web/owncloud_bkpdate +"%Y%m%d"/

it seems to have done the backup. My bad, sorry.

[maddhin]

OK, I did update to 5.0.8 but there doesn't seem to be a difference in behaviour to 5.0.7.

But there is something very interesting to tell. I added a folder to sync which was prevously "there" but got erase and found this in the log:

07-13 18:04:02:599 oc_module: Working on file Volleyball 07-13 18:04:02:599 oc_module: STAT result from propfind: Volleyball, mtime: 1373697906 07-13 18:04:02:599 oc_module: Directory of file to open exists.

This made me curious and I checked the owncloud data folder on the server: to my surprise, it looks as all files are on the server. So, the files were not erased in the folder on the server BUT in the webGUI and on the Win7 clients these files are not present.

Funny. So, there seems to be some issue between owncloud software and the data folder? It seems owncloud does not index (or whatever it does to know what data is there) properly or cannot properly communicate this index to the webgui and clients...

[maddhin]

If I run select distinct user from oc_fscache; I get #1146 - Table 'owncloud.oc_fscache' doesn't exist

if I run select distinct user from oc_filecache; which seems to be the closest table that exists, i get: #1054 - Unknown column 'user' in 'field list'

Is that helping or am I doing something wrong?

[dragotin]

@karlitschek the last two comments of @maddhin ring a bell for me about a server bug, can you remember what the issue was? Thanks.

[maddhin]

One general question to understand how owncloud works: is there any problem with directly putting files/data into the ownloud data folder on the server? Is that any different from putting data via webgui or client on the server?

I did put a lot of data on the server directly as this stroke me as the most efficient way for "initial" sync. Maybe the server "got confused and messed up" at this stage?

Although I cannot remember files missing, etc. shortly after "initial sync". Only later the client started erasing.

But the whole issue is "not only" a client bug it seems. Yesterday, when I added the "new" (but already existing folder on the server), the client recognized that the folder (files?) already exist and did upload the files BUT on the webgui the folder + files never showed and it seems now the client started erasing the folder on Win7 again (a few files already gone).

So I totally agree with @dragotin to look into server issues first.

[maddhin]

Wow, what a lovely surprise: all of sudden, the maddhin vs. Maddhin folder issue is back. When I was just logging in the webgui, all files were gone!!!

I see that the server created a new empty data folder "Maddhin" which now presents itself when logging in with EITHER 'Maddhin' (capital letter) or 'maddhin'... The original 'maddhin' folder is present on server and seemingly untouched.

How can this happen?!? HELP!!

PS: the client seems unaffected - well, at least it is not starting to erase everything (yet!?!)

Oh, my, these are grave issues...

[danimo]

@maddhin No, you cannot just put files on the server!

[maddhin]

@danimo ups... but for some reason it worked quite well though. Files showed in webgui and were synced with client...

So... I can ONLY sync files through webgui and client? So I need to download files from a non-owncloud folder on NAS/server to Win7 to upload to server again? With the crazy slow upload of the client even in the same gigabit network this would take days to bring the data to the server...

[maddhin]

@karlitschek and @dragotin: you mentioned a server bug. At the moment everything seems to be a mess. I can see that the files are on the server but one client is "sort of" syncing "most" of the files (at least the folder structure and if lucky also the files) and another client is uploading whatever but showing only a limited number of files and folders and representing what seems to be the same as the webgui.

Is there any chance to get at least the server right before trying to solve the client issues (which might only be server issues?). Should I open an issue at the core to follow this or should we do this here?

[maddhin]

Hey, guys, a brief update: for some reason, the client is now permanently uploading files again, which is quite annoying and I actually had to shut down the client as it is too much interfering with my Internet speed (practically no upload....)

Is there any news on the server bug thing?

[mkormendy]

Seems to be one of the issues I was having when files were deleted and then uploaded altogether again too.

[maddhin]

I will try 1.4.0beta2 in the next days but as of 1.4.0beta1 the issue is still persistent. Quite honestly, the client is quite busy up- n downloading although I literally didn't add any new files (for weeks). I thought it has to stop at some point but it still didn't reach that point yet... Maybe it is syncing self-produced conflict files? Dunno.

Hoping for the new beta...

[godfuture]

Having the same issue. I am uploading files whereas in the next sync cycle mostly all files get deleted. Its freakin me out.

Here a test. I have copied two pictures and two documents (JPG/DOCX) into an empty folder which is synced by owncloud client. Result: both pictures got deleted, documents remained:

Client: Win7 x64, 1.4.0 Server: IIS 7, 5.0.10

[dragotin]

@maddhin honestly, I think your setup is somehow screwed. Could you retry wtih a clean install and see if the issue still exists for you? And, you can not only put files through the Webinterface and the client, but also using a ordinary webdav client. That might suit your usecase best.

@godfuture could you please create a client logfile for me with the three files? See http://doc.owncloud.org/desktop/1.4/troubleshooting.html for details.

[maddhin]

@dragotin the 1.4.0. client since beta 2 (or was there a beta 3?) seem to have solved the problem for me. There is various new issues now (e.g. "stupid" sycncing / redownloading of already erased files - this seems to be a time stamp issue and changes do not seem to be recognized by server while a client is syncing + other inconsistencies + regular crashes and the sycning 'hangs' on certain files/folders) but it generally seems to work better and slightly faster (although syncing 10.000 or so files is still crazy slow).

BUT, I am not entirely sure if a complete sync is done already. Either the server or client hang and I cannot spend my days doube-checking if the sync is still running. But once it start erasing again, I will pronounce it here loud and clear - and will do a clean reinstall then.

[mkormendy]

I love the new interface of the latest client, and I was ready to give this thing my stamp of approval and as I watched it sync everything seemed okay on its first go. Then I waited and watched sync perform its second job,... that's when things went awry ... Here's my log on pastebin:

http://pastebin.com/uAGjqXHE

[dragotin]

This bugreport and versions are very outdated, so I will close this report.

[Mehlstaub]

I've experiencing this problem with client sync 1.5 and owncloud 6.0 What i could determine so far is that i get delete requests from the users ip addresses via the remote.php/webdav like ssl_request_log-20140302:[28/Feb/2014:13:11:09 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/3%20d%20buildings/4005556125579_Box_frontal_Export_TYP_300_CMYK_600.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:10 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Michal/4005556221561_CAT_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:11 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/displays%20%20%26%20VKK/VKK%20overview/4005556843268_VKK_Delfts%20Blauw_Export_TYP_72_RGB_648.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:11 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/PL/Dagmara%20pics%2018.12.2013/4005556074723_BOX_frontal_Internet_TYP_72_RGB_1200.jpg HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:12 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/displays%20%20%26%20VKK/VKK%20overview/4005556843251_VKK_Export_TYP_72_RGB_648.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:13 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/novinki.xlsx HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:13 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/Anleitungen/226982_24359.pdf HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:14 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Maja/4005556105182_CAT_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:15 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/3%20d%20buildings/4005556125661_Box_frontal_Export_TYP_300_CMYK_600.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:16 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/PL/Dagmara%20pics%2018.12.2013/4005556166350_BOX_frontal_Export_TYP_72_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:16 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/PL/Dagmara%20pics%2018.12.2013/4005556126583_BOX_frontal_Export_TYP_72_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:17 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/3%20d%20buildings/Overview%203%20D%20buildings.xlsx HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:18 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/Anleitungen/230963_18332.pdf HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:19 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/displays%20%20%26%20VKK/VKK%20overview/4005556947379_VKK_Pferde_Export_TYP_72_RGB_648.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:19 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Michal/4005556143290_Box_FRONTAL_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:20 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/PL/Dagmara%20pics%2018.12.2013/4005556127115_BOX_frontal_Export_TYP_72_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:21 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Maja/4005556072149_CAT_3_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:21 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Michal/4005556055845_CAT_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:22 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/PL/Dagmara%20pics%2018.12.2013/4005556131730_BOX_frontal_Export_TYP_72_RGB.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:22 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/pics%2025%2002%202014%20MPK/4005556191147_CAT_Export_TYP_75_RGB_648.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:23 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/Anleitungen/220175_21071.pdf HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:24 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/TV/Action%20Games/Billy%20Biber_16%20SEC_VERS_2.mpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:25 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Maja/4005556106394_CAT_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:26 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/displays%20%20%26%20VKK/VKK%20overview/4005556940837_VKK_Export_TYP_72_RGB_648.jpg HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:27 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/displays%20%20%26%20VKK/VKK%20overview/4005556733378_VKK_Mini_Mandala_Export_TYP_72_RGB_648.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:27 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/for%20Maja/4005556088621_CAT_2_Export_TYP_300_RGB.jpg HTTP/1.1" - ssl_requestlog-20140302:[28/Feb/2014:13:11:28 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/1steps/presentations%20%20%20TV%20%20%20%20half-cuts%20%20%20displays%20_%20%20localized%20puzzles/displays%20%20%26%20VKK/VKK%20overview/4005556946457_VKK_Export_TYP_72_RGB_648.jpg HTTP/1.1" - ssl_request_log-20140302:[28/Feb/2014:13:11:28 +0100] 10.1.5.49 TLSv1.2 DHE-RSA-AES256-GCM-SHA384 "DELETE /remote.php/webdav/3%20d%20buildings/12568.jpg HTTP/1.1" -

which have not been done by the users manually. So it happens that some cloud storages randomly get nearly completely deleted without the user doing something.

[simonjwoolf]

This issue is still occurring in windows client 1.7, with owncloud 7.0.2

Behaviour is exactly as desribed in the beginnning of this issue - a new file or folder is created by one user, and then the windows clients connected to owncloud promptly delete it a few minutes later.

[Mehlstaub]

We still have this problem too, meanwhile we decided to move away from the sync client as it to dangerous for us to lose data.

[LukasReschke]

This issue is over one year old. It is very unlikely that the root cause is exactly the same, we'd therefore greatly appreciate it if you could open a new bug report instead of hijacking this old one.

No developer likes scrolling through a lot of logs of a lot of different versions. Let's make the live for each of us easier: For us developers by making it easier to reproduce the bug, for you users because we can help you better.