search

nextcloud / desktop

💻 Desktop sync client for Nextcloud
https://nextcloud.com/install/#install-clients
GNU General Public License v2.0
3.04k stars 799 forks source link

Client deleted my files #260

Closed Dennis1993 closed 3 years ago

Dennis1993 commented 6 years ago

Hey,

yesterday my nextcloud sync client on my windows Server 2016 deletes one folder with 8.2 GB files! I can't sync it back. On my local hard drive are all files removed. Online in nextcloud the files are there. Where I can find the log? It is a bug? What can I do to resync the files? Which info are useful to find the bug?

EDIT: I can see the message in the log "Stat fehlgeschlagen" for the files... WHY?

My log file:

=#=#=# Syncrun started 2018-04-22T19:14:06

=#=#=#=# Propagation starts 2018-04-22T19:14:15 (last step: 9314 msec, total: 9314 msec)

||SERVER/SCANS/myfile1.docx|INST_REMOVE|Down|1489405946||82177||4||0|0|0|||INST_NONE| ||SERVER/SCANS/myfile2.docx|INST_REMOVE|Down|1494413064||16962||4||0|0|0|||INST_NONE| ||SERVER/SCANS/myfile3.docx|INST_REMOVE|Down|1521020340||17214||4||0|0|0|||INST_NONE|

THOUSAND OF ENTRIES LIKE THIS ABOVE

=#=#=# Syncrun finished 2018-04-22T19:14:37 (last step: 21886 msec, total: 31200 msec)

=#=#=# Syncrun started 2018-04-22T19:14:46

=#=#=#=# Propagation starts 2018-04-22T19:14:55 (last step: 9200 msec, total: 9200 msec)

=#=#=# Syncrun finished 2018-04-22T19:14:55 (last step: 106 msec, total: 9307 msec)

=#=#=# Syncrun started 2018-04-22T19:15:33

=#=#=#=# Propagation starts 2018-04-22T19:15:35 (last step: 2098 msec, total: 2098 msec)

=#=#=# Syncrun finished 2018-04-22T19:15:35 (last step: 43 msec, total: 2141 msec)

=#=#=# Syncrun started 2018-04-22T19:29:46

=#=#=#=# Propagation starts 2018-04-22T19:29:47 (last step: 1150 msec, total: 1150 msec)

=#=#=# Syncrun finished 2018-04-22T19:29:47 (last step: 44 msec, total: 1195 msec)

It works since January of 2018 but yesterday that... :(

EDIT2: I found more Information about this bug. Maybe it is a Server problem and not a client problem?! I use the latest NC13.0.1 on ALL-INKL.COM with PHP 7.2 and MySQL 5.7

unbenannt

unbenannt2

camilasan commented 6 years ago

Considering the logs, you can look for help in the forums help.nextcloud.com. It does not look like a client problem. You should review your server settings/configuration.

michel-thomas commented 6 years ago

@Dennis1993 Have you solved your problem?

A user has the same problem you describe: files and folders disappear whereas they are still present and valid on the server, and accessible with web GUI.

My user have this config:

Client GUI does not shows any error. I asked for logs, I will have it soon.

This concerns a shared folder owned by another nextcloud user, but from what I know, no one else is concerned by this problem.

I also precise that this is not a new install, it works since more than a year, and this problem appears since 31 of may, so not so long after server upgrade to 13.0.1 (done in april the 3rd).

If you have anything that could help...!

michel-thomas commented 6 years ago

Removing ._sync_5a2191865723.db, ._sync_5a2191865723.db-shm and ._sync_5a2191865723.db-wal has solved the problem. Scan has been redone and downloading of missing files and folders have been done successfully.

But I don't know what happened, so here is an extract concerning a folder which was incomplete due this problem

06-03 21:01:46:522 0xa487b54 sqlite_profile: _SQL_ SELECT phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildrenRemote, contentChecksum, contentChecksumTypeId FROM metadata WHERE phash=?1: 0
06-03 21:01:46:523 0xa487b54 _csync_detect_update: Database entry found, compare: 1528036910 <-> 1527677889, etag: (null) <-> 5b0e83c1a1217, inode: 41416 <-> 41416, size: 4096 <-> 0, perms:  <-> SRGDNVCK, ignore: 0
06-03 21:01:46:523 0xa487b54 _csync_detect_update: file: Commun/Formation/2018, instruction: INSTRUCTION_EVAL <<=
06-03 21:01:46:523 0xa487b54 csync_walker: directory: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/facilitation graphique [inode=4637]
06-03 21:01:46:523 0xa487b54 sqlite_profile: _SQL_ SELECT phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildrenRemote, contentChecksum, contentChecksumTypeId FROM metadata WHERE phash=?1: 0
06-03 21:01:46:523 0xa487b54 _csync_detect_update: Database entry found, compare: 1527679461 <-> 1527677054, etag: (null) <-> 5b0e807e61117, inode: 4637 <-> 4637, size: 4096 <-> 0, perms:  <-> SRGDNVCK, ignore: 0
06-03 21:01:46:523 0xa487b54 _csync_detect_update: file: Commun/Formation/2018/facilitation graphique, instruction: INSTRUCTION_EVAL <<=
06-03 21:01:46:523 0xa487b54 csync_ftw:  <= Closing walk for /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/facilitation graphique with read_from_db 0
06-03 21:01:46:523 0xa487b54 csync_walker: file: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/Inscriptions prév formations 2018_conflict-20180529-115655.xls [inode=5785 size=81408]
06-03 21:01:46:523 0xa487b54 _csync_detect_update: Commun/Formation/2018/Inscriptions prév formations 2018_conflict-20180529-115655.xls excluded  (1)
06-03 21:01:46:523 0xa487b54 csync_walker: file: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/Programme2018_conflict-20171207-182339.ods [inode=41437 size=18289]
06-03 21:01:46:525 0xa487b54 _csync_detect_update: Commun/Formation/2018/Programme2018_conflict-20171207-182339.ods excluded  (1)
06-03 21:01:46:525 0xa487b54 csync_ftw:  <= Closing walk for /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018 with read_from_db 0
06-03 21:01:46:525 0xa487b54 csync_walker: directory: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/Administratif [inode=146633]
06-03 21:01:46:525 0xa487b54 sqlite_profile: _SQL_ SELECT phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildrenRemote, contentChecksum, contentChecksumTypeId FROM metadata WHERE phash=?1: 0
06-03 21:01:46:525 0xa487b54 _csync_detect_update: Database entry found, compare: 1527680606 <-> 1527679844, etag: (null) <-> 5b0e8b6525fc6, inode: 146633 <-> 146633, size: 4096 <-> 0, perms:  <-> SRGDNVCK, ignore: 0
...
06-03 21:03:02:420 0xa214da0 _csync_merge_algorithm_visitor: INSTRUCTION_NONE               client dir:  Commun/Formation/2018/facilitation graphique
...
06-03 21:03:02:826 0xa214da0 _csync_merge_algorithm_visitor: INSTRUCTION_NONE               client dir:  Commun/Formation/2018
...
06-03 21:03:41:298 0xa487b54 csync_walker: directory: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018 [inode=41416]
06-03 21:03:41:298 0xa487b54 sqlite_profile: _SQL_ SELECT phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildrenRemote, contentChecksum, contentChecksumTypeId FROM metadata WHERE phash=?1: 0
06-03 21:03:41:298 0xa487b54 _csync_detect_update: Database entry found, compare: 1528036910 <-> 1527677889, etag: (null) <-> 5b0e83c1a1217, inode: 41416 <-> 41416, size: 4096 <-> 0, perms:  <-> SRGDNVCK, ignore: 0
06-03 21:03:41:298 0xa487b54 _csync_detect_update: file: Commun/Formation/2018, instruction: INSTRUCTION_EVAL <<=
06-03 21:03:41:299 0xa487b54 csync_walker: directory: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/facilitation graphique [inode=4637]
06-03 21:03:41:299 0xa487b54 sqlite_profile: _SQL_ SELECT phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildrenRemote, contentChecksum, contentChecksumTypeId FROM metadata WHERE phash=?1: 0
06-03 21:03:41:299 0xa487b54 _csync_detect_update: Database entry found, compare: 1527679461 <-> 1527677054, etag: (null) <-> 5b0e807e61117, inode: 4637 <-> 4637, size: 4096 <-> 0, perms:  <-> SRGDNVCK, ignore: 0
06-03 21:03:41:299 0xa487b54 _csync_detect_update: file: Commun/Formation/2018/facilitation graphique, instruction: INSTRUCTION_EVAL <<=
06-03 21:03:41:299 0xa487b54 csync_ftw:  <= Closing walk for /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/facilitation graphique with read_from_db 0
06-03 21:03:41:299 0xa487b54 csync_walker: file: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/Inscriptions prév formations 2018_conflict-20180529-115655.xls [inode=5785 size=81408]
06-03 21:03:41:299 0xa487b54 _csync_detect_update: Commun/Formation/2018/Inscriptions prév formations 2018_conflict-20180529-115655.xls excluded  (1)
06-03 21:03:41:299 0xa487b54 csync_walker: file: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018/Programme2018_conflict-20171207-182339.ods [inode=41437 size=18289]
06-03 21:03:41:299 0xa487b54 _csync_detect_update: Commun/Formation/2018/Programme2018_conflict-20171207-182339.ods excluded  (1)
06-03 21:03:41:300 0xa487b54 csync_ftw:  <= Closing walk for /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/2018 with read_from_db 0
06-03 21:03:41:300 0xa487b54 csync_walker: directory: /home/frcivam-bzh/Data/cloud FR BZH/Commun/Formation/Administratif [inode=146633]
06-03 21:03:41:300 0xa487b54 sqlite_profile: _SQL_ SELECT phash, pathlen, path, inode, uid, gid, mode, modtime, type, md5, fileid, remotePerm, filesize, ignoredChildrenRemote, contentChecksum, contentChecksumTypeId FROM metadata WHERE phash=?1: 0
06-03 21:03:41:300 0xa487b54 _csync_detect_update: Database entry found, compare: 1527680606 <-> 1527679844, etag: (null) <-> 5b0e8b6525fc6, inode: 146633 <-> 146633, size: 4096 <-> 0, perms:  <-> SRGDNVCK, ignore: 0
06-03 21:03:41:300 0xa487b54 _csync_detect_update: file: Commun/Formation/Administratif, instruction: INSTRUCTION_EVAL <<=

Any idea? Thanks for your help.

Dennis1993 commented 6 years ago

Hey,

I habe no idea why the files and folders are deleted. I have downloaded the files from the webinterface and copied it manually.

Now it works but I don’t know how long. I have copied all my files in another folder too, to restore my files quickly when the problem appears. This is the second time and I don’t know why. I host my Nextcloud on All-Inkl.com since 2016 and the problem exists since 2018 with Nextcloud 13 and the latest desktop sync client on windows.

camilasan commented 6 years ago

@Dennis1993 did you try what @esprit-libre mentioned? Do you have any client logs? I am sorry for taking too long to reply.

Dennis1993 commented 6 years ago

How I wrote. I copied the files manually back and now it works. But I don't know why. I have only the posted logs and screenshots from my first post.

Dennis1993 commented 5 years ago

Today the same problem, All my files are deleted and syncing again from the Cloud to my Windows 10 notebook. I don't know why...

theroch commented 5 years ago

We have the same issue. All files are unexpectly deleted from local clients (not from server). Then the client begins to resync all files from server. The removed folder is an global external storage to an smb share with session authentication. We use latest nextcloud 14 with desktop client 2.5.0.

theroch commented 5 years ago

Today the nextcloud client (2.5.1) removed my external storage again on a Windows 10 (x64) notebook. ||ext_storage|INST_REMOVE|Down|1546713760||12288||4||0|0|0|||| With this issue the client is not usable anymore!

theroch commented 5 years ago

Strange behavior, under Windows 7 (x64) desktop pc with nextcloud client 2.5.1 the folder will never be removed. Does the removal perhaps have something to do with the standby mode on the notebook?

theroch commented 5 years ago

Today the nextcloud client (2.5.1) removed my external storage again on a Windows 10 (x64) notebook after standby mode.

theroch commented 5 years ago

Maybe I've found a workaround. I've changed the authentication mechanism from Log-in Credentials, save in session to Log-in Credentials, save in database. Now the issue seems to be gone away. That's not the best choice from a security point of view, but much better than always losing all your data.

Maybe someone else can confirm that?

So the problem seems to be related to the authentication mechanism. I'll keep watching that for the next few days.

Fluotonic commented 5 years ago

Hey everyone,

I got the same problem twice with the new client (2.5.1), on macOS Sierra and Nextcloud 15 on our server. First time, I thought it was some error or misconfiguration on the server, on which we were still working. But the second time, the server was fine and everything was set up and running nicely. But all of a sudden, bam! 60GB disappeared from my desktop!!! Fortunately, everything was kept on the server, but I still had to download again everything... Which is always a pain, even with a good connection!

How I did on my end is:

  1. uncheck the folder with missing content, from the Desktop client
  2. force sync
  3. check the folder again
  4. force sync again and wait for everything to be downloaded again

I have to precise that I have a local backup with Time Machine, but I don't really know what would happen if I use a backed up version of my files. Wouldn't they have different timestamps and mess everything up? I'm not really sure of this one... but at the end I preferred to re-download everything to be sure everything was correctly synchronized.

In the server logs, I couldn't find anything. And on the app, it looks like you have to actually open the log window to start recording? If that's the case, well... I can't see anything obviously.

Anyway, does anyone know if this bug is going to be fixed in the next version? This is a serious bug in my humble opinion, and I know a couple of my clients who will freak out if this happens to them.

Thanks for this great app, by the way, and keep up the good work! Let me know how I can help :-)

hataos commented 5 years ago

Hey all,

I am having the same issue on Windows 10 with client version 2.5.1final (build 20181204) and Nextcloud 16.

The client log file shows entries like this:

=#=#=# Syncrun started 2019-06-26T15:20:41Z

=#=#=#=# Propagation starts 2019-06-26T15:21:12Z (last step: 31494 msec, total: 31494 msec)

||file/path|INST_REMOVE|Down|1543877229||0||4||0|0|0|||| ||file/path|INST_REMOVE|Down|1553782110||4096||4||0|0|0|||| ||file/path|INST_REMOVE|Down|1559437692||16384||4||0|0|0|||| ||file/path|INST_REMOVE|Down|1559248228||12288||4||0|0|0|||| ||file/path|INST_REMOVE|Down|1543877185||4096||4||0|0|0||||

Etc.

I noticed that this happened as the hard drive I was syncing to was nearing its space limit and that the folder deleted was the largest of all synced folders.

Let me know if I can provide any other information to help.

Thanks for all the work on this great software!

Edit: actually, it just happened again, with another folder on another (external) drive with plenty of storage space left. The issue is starting to worry me - are there any ideas about the cause / a potential fix?

MPCNextCloud commented 5 years ago

Hey all, same issue at our environment: We are using NC 16 and Win-Client 2.5.1. Among other things, we are synchronizing between a Windows-network-share and our Nextcloud over the NC-win-Client which is localy installed on the Win10-Clients. So far, everything is working fine.

But, if I change my network-connection from LAN to our WLAN (which is also part of our Domain) and sometime later back to LAN, my NextCloud-Client is deleting a bigger part of my files and folders in the network-share. The other Sync-Folders (which are not located on a network-share) are NOT affected of this step. At the same time, my windows error-log is showing the following error seven times:

mrxsmb 139

So this Windows-Event is deciding for the losing/synchronizing the data…

Did anybody of you have a similar issue? Have you ideas of solutions?

Thanks a lot! Regards Chris

j2g2rp commented 5 years ago

Hi I experienced two times this problem. In my case I'm using ubuntu 18.04 in several clients. I don't know if is possible that if any folder is lost (for example the folder is an external device which is unmounted accidentally) the client can "think" that the folder were deleted and delete it from server and clients

Dennis1993 commented 5 years ago

I have no external drives in my nextcloud. I only use the default "data"-folder. Maybe it is another problem.

Reil commented 5 years ago

Same symptoms. New NextCloud installation as of last weekend. Today, my client blasted a few folders seemingly unprovoked, but they appear to still be on the server, according to the client and the web interfaces.

camilasan commented 5 years ago

Is this still happening with the latest client 2.6 rc1?
https://github.com/nextcloud/desktop/releases/tag/v2.6.0-rc1

or the 2.5.3? https://github.com/nextcloud/desktop/releases/tag/v2.5.3

Thanks

Reil commented 5 years ago

I'm on 2.5.3daily-Win64 (build 20190725), talking to server on 16.

phsc84 commented 5 years ago

I can confirm this problem on Windows client 2.5.3.

camilasan commented 5 years ago

Is it the same for 2.6 rc1?

phsc84 commented 5 years ago

I've just completely deinstalled client 2.5.3 (including config) and installed client 2.6rc1. I will survey the behaviour the next days. Unfortunately it is quite difficult, because it only occurred occasionally. But my setup is as follows:

phsc84 commented 5 years ago

So far, the problem did not occur with 2.6rc1 anymore. My usage of the system did not differ from the usage, when I had the problem with 2.5.3. Therefore I am carefully optimistic, that the problem has been resolved with 2.6rc1. I will now install 2.6final.

Dimasmidbass commented 5 years ago

Hello, I have the same problem with Notebook on Windows 8.1. Files just dissappears from local drive, nothing in logs, on the server files are present. This was happend 4-5 times. It was with Owncloud, Nextcloud 11,13,15. It was with clien some old, 2.3, 2.5, 2.6. Also I have reinstalled whole windows, change HDD, change location of the folder. Of couse I have done it with anothe reasons, but i want to say that this problem is very old, and still present.

And it happends again and agian, at night after server go out of maintance mode. Client log file:

[_csync_merge_algorithm_visitor INSTRUCTION_NEW server file: XXXXX.XXX [_csync_merge_algorithm_visitor INSTRUCTION_NEW server file: XXXXX.XXX [_csync_merge_algorithm_visitor INSTRUCTION_NEW server file: XXXXX.XXX ...... [csync_reconcile Reconciliation for remote replica took 52.353 seconds visiting 77978 files. [OCC::SyncEngine::slotDiscoveryJobFinished #### Reconcile end #################################################### 959386 ms [OCC::SyncEngine::checkErrorBlacklisting blacklist entry for "YYYYYYYY/YYYYY/YYY.YYY" has expired! [OCC::SyncEngine::slotDiscoveryJobFinished Permissions of the root folder: "DNVCKR" [OCC::SyncJournalDb::commitTransaction ERROR committing to the database: "cannot commit - no transaction is active" [OCC::SyncEngine::deleteStaleDownloadInfos Deleting stale temporary file: "XXXXXX.XXXX" [OCC::SyncEngine::deleteStaleDownloadInfos Deleting stale temporary file: "XXXXXX.XXXX" [OCC::SyncEngine::deleteStaleDownloadInfos Deleting stale temporary file: "XXXXXX.XXXX" ..... and so on, million files

vincentqb commented 4 years ago

This happened just now with desktop client 2.5.3git and with 2.6.2git on ubuntu 18.04.

vincentqb commented 4 years ago

related owncloud/client#6322 and their fix?

dermitdemwolf commented 4 years ago

Hey all, same issue at our environment: We are using NC 16 and Win-Client 2.5.1. Among other things, we are synchronizing between a Windows-network-share and our Nextcloud over the NC-win-Client which is localy installed on the Win10-Clients. So far, everything is working fine.

But, if I change my network-connection from LAN to our WLAN (which is also part of our Domain) and sometime later back to LAN, my NextCloud-Client is deleting a bigger part of my files and folders in the network-share. The other Sync-Folders (which are not located on a network-share) are NOT affected of this step. At the same time, my windows error-log is showing the following error seven times:

mrxsmb 139

So this Windows-Event is deciding for the losing/synchronizing the data…

Did anybody of you have a similar issue? Have you ideas of solutions?

Thanks a lot! Regards Chris

Hi Chris,

we have exactly the same situation. Nextcloud 16 but the mac client instead. I can approve the same behavior in different network environments. Did you get a chance to solve this issue? Or did you find at least a feasible way-around? Or somebody else, out there? :-)

Thanks

michel-thomas commented 4 years ago

Hello, last week a user complained about large number of files and folders deleted. From server side, it appears that deletion has been initiated by client, but the user is sure not having done such operation. Deleted files and folders are owned by this user and are shared with one group of users. Lot of space available on user's hard drive. nextcloud-client is 2.6.4 Windows 10 x64 Nextcloud server is 18.0.4 Unfortunately I don't have nc-client logs. If someone also have this bug, how to avoid it for future?

phsc84 commented 4 years ago

I also had this behavior several times. Unfortunately it is not really reproducible. But I noticed, that - at least for me - it occurs on a Windows 10 x64 client, where data are stored on a linux network share (connected via samba). And after booting Windows 10, you have to click on the network share, that Windows recognizes the availability of the network share. If - and that's the point - don't do that, sometimes files get deleted by the Nextcloud client.

michel-thomas commented 4 years ago

Thanks @phsc84 for the feed back. But in my case, the user is with laptop on its hard drive only.

laurenzroth commented 4 years ago

A user of mine had this last week. Only happens on Windows computers. The user uses client 2.6.4 on Windows 10 build Version 1903 (OS Build 18362.959).

er-vin commented 4 years ago

Is it me or this one and #1433 are the same issue?

DominiqueFuchs commented 4 years ago

@er-vin Can't rule out any correlation, but the issue you mentioned is all about going UP (local files stay intact, server get's false REMOVEs)

er-vin commented 4 years ago

Ah yes good point, different direction. Not a dup then.

dnlfrst commented 4 years ago

I experienced this issue today on macOS Catalina (Version 10.15.5) using the Desktop Client Version 2.3.3 (build 84) with a server running Nextcloud 15.0.11. Roughly half of the data synchronized (~15 GB) have been deleted locally overnight while the deleted files are still available on the server. The workaround posted by @Fluotonic helped to mitigate this problem.

camilasan commented 4 years ago

Desktop Client Version 2.3.3 (build 84) with a server running Nextcloud 15.0.11

honest question: why are you using such old versions of the client and the server?

dnlfrst commented 4 years ago

honest question: why are you using such old versions of the client and the server?

I do not bother to manually track updates to the client. Unfortunately, the client does not seem to care about updates either as it states that I am on the most recent version. Other than reinstalling, I do not see a way to update the client. Since I am not sure whether I can reinstall the client without re-syncing all files, I seem to be stuck on this client version. Risking to re-sync all my files is not an option as this would take ages due to the slow synchronization process.
As for the server, I sadly cannot remember an update that did not break the Nextcloud installation requiring me to manually fix it. I am not willing to invest my time for something that this very software should do automatically, hence I won't update the Nextcloud instance as long as I am not forced to.

dnlfrst commented 4 years ago

I experienced this issue today on macOS Catalina (Version 10.15.5) using the Desktop Client Version 2.3.3 (build 84) with a server running Nextcloud 15.0.11. Roughly half of the data synchronized (~15 GB) have been deleted locally overnight while the deleted files are still available on the server. The workaround posted by @Fluotonic helped to mitigate this problem.

I just realized that while the mentioned mitigation does trigger the synchronization process in the client which shows that the files are being downloaded, none of them actually appear in my local file system, so the workaround does not actually appear to work.

dnlfrst commented 4 years ago

The above-described issue just occurred again. This time on macOS Catalina (10.15.6) using the Desktop Client Version 2.6.5 with a server running Nextcloud 17.0.8. There are only two files of my synchronized files left on this device, i.e., the Nextcloud client deleted roughly 32 GB overnight.

Ricardosgeral commented 4 years ago

SOMEONE NEEDS TO LOOK AT THIS. 3RD time it happened to me!!

This is like Chernobyl at Nextcloud gmbh All the signs are visible

SOMEONE FIX THIS OR PEOPLE WILL LEAVE THE APP

cluxter commented 4 years ago

SOMEONE FIX THIS OR PEOPLE WILL LEAVE THE APP

This is what I ended up doing a couple of years ago. I left Nextcloud for Seafile and this was actually the best move I could do. Performances are incredible, what used to take 6 hours to synchronize on Nextcloud now takes 10 minutes on Seafile because of the way they handle small files, cache and connections. It's also made by design to make sure you never lose data, it's highly reliable. It also offers client side encryption and many other nice features.

You should seriously give it a try. After trying it and benchmarking it for 2 days at the beginning, it looked very promising. After 2 years of using it on a daily basis both for work and private stuff, let me tell you: I would never ever go back on Nextcloud. To me Seafile is an order of magnitude better than Nextcloud. It does less things, but it does them perfectly.

I hate doing that here but hey, this bug hasn't been fixed in years so it's safe now to say that Nextcloud doesn't care at all about your data and the user experience, or that they are not skilled enough to do so. You deserve something better so give yourself the opportunity to use a (way) better product.

EDIT: I really tried to make them fix this critical bug 2 years ago before considering trying something else, but the way they took care of the situation convinced me to look for something else. See here: https://github.com/nextcloud/desktop/issues/289#issuecomment-438080304

EDIT 2: like seriously: https://github.com/nextcloud/desktop/issues/703#issuecomment-438489811

jancborchardt commented 4 years ago

Even though the issue is annoying, please keep comments on topic and constructive so people can focus on tracking down the problem. If you just agree with the issue, use the :+1: reaction feature on the original post. Thanks.

cluxter commented 4 years ago

It's hard to keep on being constructive when the official team basically ignores your bug reports and debugs for 2 years, not on a cosmetic glitch but on a critical core feature bug, and finds time to censor your comments but not enough time in 2 years to address this nuclear problem.

You had several constructive bug reports from myself and other people for 2 years now and the two things you did so far were ignoring or censoring people about it.

This issue is not annoying, it's - again - critical. What's annoying is how you address it (or basically how you do not).

I asked to reopen an issue to work on it to fix it myself and the only thing I got was "Just try to update the client". Nothing else.

So if you think I'm not being constructive enough/anymore, please tell me what I can do better because I tried what I could but I faced a team of people who do not accept criticism and are not willing to let me work on their critical bugs.

Crazy.

mburnicki commented 4 years ago

Sorry, but I have to agree with @cluxter. Fortunately this hasn't happened to me, yet, but I hesitate to update the client software (Linux and Windows) because I'm afraid to run into the problems reported here.

Ricardosgeral commented 4 years ago

I'm with you @cluxter I'm also wondering. Nexcloud sells the service alsweell. Why don't they have these problems with their own payed clients? They must have the same issues...

Fluotonic commented 4 years ago

Yep, I also agree with @cluxter. This issue is not something only "annoying". This is a real turnoff for users, especially as most of us here have started using Nextcloud because it was supposedly safer for our data. I mean... privacy is one thing, but security (not loosing data) is maybe even more important, in my opinion.

I can't believe, as @Ricardosgeral pointed out, that you guys at Nextcloud didn't have to deal with this issue already with your paid clients. A bit of transparency on this matter would be greatly appreciated.

This application is great otherwise, but I'm afraid this data loss problem is CRITICAL and might play against you guys in the long run. This very long awaiting fix is not about user experience, as you seem to suggest. It is about SECURITY, plain and simple.

Thanks in advance for your consideration and keep up the good work!

Fluotonic commented 4 years ago

On a more technical side, I'd like to continue and try helping you guys nail it. So here we go...

I noticed this issue happened once when my external HDD (the one that is synchronized to Nextcloud) crashed. Basically, the disk was still running but nothing could be written on it, even using macOS Finder or even the Terminal. I could read it though, but I couldn't write anything.

So I have the following suggestion for you guys: the problem COULD be linked to the fact that the app is sometimes no longer able to write locally (whatever it is trying to write, even metadata). Then, the whole thing goes out of sync and MAYBE the app ends up removing local content, not strictly speaking, but "unchecking" synchronization for all (or a few) folders. Why it would do that? No idea, but I suppose you guys could find out as you created all the logic behind the scene.

This is only me thinking, of course. But I figure that you guys could easily reproduce this, maybe playing with disk permissions or something.

Anyway, this was my two cents :-)

Reil commented 4 years ago

I understand your frustrations, and feel them as a user who had to deal with this bug starting out. However, I'm subscribed to this thread to see technical updates on the bug -- to hopefully find a common source of the problem, or a workaround, or an update with a fix to the problem. I'm not here to read general complaints or have them fill my inbox with false hope of actual progress. Please stay on topic.

dnlfrst commented 4 years ago

I noticed this issue happened once when my external HDD (the one that is synchronized to Nextcloud) crashed. Basically, the disk was still running but nothing could be written on it, even using macOS Finder or even the Terminal. I could read it though, but I couldn't write anything.

On my MacBook (macOS), I only have one internal SSD. However, I noticed that in both the above-described occasions where Nextcloud deleted (parts of) my files said SSD was almost full with only a few MBs left. This seems to be similar to what @Christophe31 describes in another issue:

I had same Issue… Not sure it's linked but my / partition (including /tmp and /var) is ~100% full. (ubuntu). (while my home partition containing my synced nextcloud folder had remaining space)

I would like to note, though, that the lack of disk space might not necessarily be related to the deleted files. While I run out of disk space every few days, Nextcloud only deleted files on two of those occasions as elaborated earlier.