Client deleted my files #260

Dennis1993 · 2018-04-23T06:22:16Z

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

camilasan · 2018-04-23T08:25:19Z

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 · 2018-06-03T19:43:37Z

@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:

xUbuntu 17.10
nextcloud-client 2.3.3
sync is done in a folder shared with Windows session (mount is done with root with 777 right mask)

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 · 2018-06-04T17:58:42Z

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 · 2018-06-04T19:12:51Z

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 · 2018-06-04T21:05:54Z

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

Dennis1993 · 2018-06-21T20:56:07Z

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 · 2018-11-17T19:46:14Z

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 · 2019-01-05T14:39:08Z

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 · 2019-01-07T06:13:13Z

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 · 2019-01-12T11:48:22Z

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 · 2019-01-14T19:24:21Z

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

theroch · 2019-02-02T07:59:36Z

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 · 2019-02-28T17:26:06Z

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:

uncheck the folder with missing content, from the Desktop client
force sync
check the folder again
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 · 2019-06-26T16:34:02Z

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 · 2019-08-02T07:41:14Z

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 · 2019-08-17T17:40:40Z

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 · 2019-08-17T18:18:45Z

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

Reil · 2019-09-17T03:10:08Z

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 · 2019-09-18T16:02:04Z

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 · 2019-09-19T01:58:20Z

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

phsc84 · 2019-09-19T07:20:04Z

I can confirm this problem on Windows client 2.5.3.

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913 Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>

ChagnonG · 2021-03-19T10:11:05Z

@FlexW There is no cleanup software on my system. I could not figure out on which base the files were deleted/kept: old files were still there, and some of the new ones were missing. New directories were emptied.

Looking at the log with more attention I realize the deletions occured yesterday evening, when I was doing a system update (Manjaro=rolling release…). As this software update filled the disk, I do not know if the problem was a network issue (downloading the packages while synchronizing) or a disk capacity one.

I cannot drop the log file to the instance you provided, as I cannot log in. So here is an extract: from last new file uploaded before the event to the first one new one this morning when I loggeg in:

partLog.log

FlexW · 2021-03-19T10:17:46Z

@ChagnonG I'm sorry I provided you the wrong link. I corrected it.

ChagnonG · 2021-03-19T12:13:27Z

@FlexW Thank you, I uploaded the whole log this time (besides, the structure of my nextcloud is not interresting for everyone ;-) ): you will perhaps find any clue about what happened in previous records…

er-vin · 2021-03-19T12:42:46Z

I tried to reproduce the scenarios described here on Windows and Linux. When my drives got full, the client behaved correctly: It stopped to sync but didn't delete anything.

Out of curiosity, was it with 3.1 or master? There's been more strengthening and handling of db write failures introduced, this could explain. It'd be good news if that turns out to finally kill #260 and #1433

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913 Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>

FlexW · 2021-03-22T11:13:58Z

I tried to reproduce the scenarios described here on Windows and Linux. When my drives got full, the client behaved correctly: It stopped to sync but didn't delete anything.

Out of curiosity, was it with 3.1 or master? There's been more strengthening and handling of db write failures introduced, this could explain. It'd be good news if that turns out to finally kill #260 and #1433

I had with both versions no deletion issues.

FlexW · 2021-03-22T11:35:19Z

@FlexW Thank you, I uploaded the whole log this time (besides, the structure of my nextcloud is not interresting for everyone ;-) ): you will perhaps find any clue about what happened in previous records…

Did you strip the logs? From what you sent me I can only tell that the client removed the files because it thought they were removed from the server. Now it's unclear to me why the client thought this if the files were still on the server. We would probably need detailed logs from the server and client from the time the removal occured.

ChagnonG · 2021-03-22T11:50:03Z

@FlexW No, I didn't strip the logs. I'm afraid I don't have access to the logs on the server (it's a shared hosting). I; will get in touch with the support team and if I can provide you with the logs, I will send them. But don't be too optimistic…

shurik-io · 2021-03-30T18:16:18Z

I was already aware, that under some normal user behavior, the sync client removes the local files. But today, i recognized, that if I remove a subfolder from the syncjob, the sync client DELETED the whole local folder. Most data of the folder, where some .qcow2 images are stored, are ignored anyway, thus not laying on the server side. Yep, these VMs are gone now, because IMHO no one even think about how to implement a correct 2-way sync to avoid data loss at as many scenarios as possible.

I know it's hard. But please, for everyone's peace of mind, ask the user what to do, or even warn the user, if a subfolder is removed, or even the sync job, that it will delete the local files on the client side. This issue is open since almost 3 years, and people reporting it multiple times. How much data must be lost, because of a really misbehaving piece of software, that you don't want to fix!? IMO this is a key feature. Instead new features are more important to create, than fixing existing things.

Yes, this is kinda of a bug+improvement rant. But in the end, I would like to understand the design decisions behind it. Why was it implemented that way? Is there maybe a good reason for it?

FlexW · 2021-03-31T07:38:01Z

@shurik-io I'm sorry that this happened and can feel your anger. Your issue sounds a lot different from what the other people in this thread faced. I'm not the designer of the sync algorithm, and the people that have designed it are long gone. My best bet would be that no one has thought about that particular case so far. Your report sounds like a bug and needs fixing, and I have it on my list now. It would be great if you create a separate issue with a detailed description of how to reproduce the problem and try to reproduce it with the latest pre-release (at this moment, it is 3.2.0-rc2). That would speed up the development of a fix. This thread has become a bucket for all kind of different removal reports, and the original issue might even be solved.

I tried to reproduce the issues people faced but were not able to do so. If I'm not able to reproduce it, then it is nearly impossible to deliver a fix. Just for your information, the upcoming update 3.2.0 contains a major overhaul of the sync engine that will likely fix a lot of issues.

Please also note that there is config option that when enabled moves files to the trash instead of deleting them. With that option enabled you should be save in all situations. We discussed internally about enabling that option by default, but we're afraid that as soon as we enable that by default, people start to report bugs that their hard drive gets full. In most situation, the client behaves fine and does the correct thing. Introducing a dialog that would ask the user about every file that gets removed would annoy a lot of users, I guess. I know you could introduce another config option for that, but the goal should be to make the sync engine behave correct in all situations. After all, I use the client for a few years now and never had my files deleted.

chainria · 2021-03-31T08:40:09Z

I just noticed that Gentoo still uses 2.6.5. I will try to update to the newest "unstable" version, which is 3.1.3 for now. Not feeling all too adventurous though, losing my files three times was more than enough.

github-actions · 2021-05-06T02:23:17Z

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

To better see what is going on when and if files are removed by the client. See also: #260, nextcloud#1433, nextcloud#2913 Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>

Klemet · 2021-07-01T15:27:23Z

I think that I just had the same issue, but I'm not sure. Here's the quick story :

Had a corrupt windows installation on C:, and Nextcloud data on D:.
I reinstall windows, and reinstall the Nextcloud client. Former Nextcloud data is still there on D:.
When the Nextcloud client asks me for the folder to sync the files to, I choose another folder than the former Nextcloud data, because I previously had the issue where syncing in a former Nextcloud data folder deleted all of the data server-wise.
When the sync begin, I pause it so as to copy the former Nextcloud data into the new sync folder (in order to avoid re-downloading all of my data for nothing). However, doing this, I realize that the former Nextcloud data folder has been entirely deleted. It's not even present in the recycle bin.

I guess that the Nextcloud Client did it, for I don't see what else could have had. Sadly, the log wasn't activated, so I have no way to see how and why it was done for sure.

mgallien · 2021-07-02T11:08:24Z

I think that I just had the same issue, but I'm not sure. Here's the quick story :

* Had a corrupt windows installation on `C:`, and Nextcloud data on `D:`.

* I reinstall windows, and reinstall the Nextcloud client. Former Nextcloud data is still there on `D:`.

* When the Nextcloud client asks me for the folder to sync the files to, I choose another folder than the former Nextcloud data, because I previously had the issue where syncing in a former Nextcloud data folder deleted all of the data server-wise.

* When the sync begin, I pause it so as to copy the former Nextcloud data into the new sync folder (in order to avoid re-downloading all of my data for nothing). However, doing this, I realize that the former Nextcloud data folder has been entirely deleted. It's not even present in the recycle bin.

I guess that the Nextcloud Client did it, for I don't see what else could have had. Sadly, the log wasn't activated, so I have no way to see how and why it was done for sure.

I think that you problem is unrelated to this bug that is about a bug when disc is almost full and internal state of the client gets corrupted until it sends delete order to the server.
Your problem seems highly unrelated to that given you had plenty of space and you did some manipulations. Please open another issue for your problem (but only if you are able to provide information otherwise we will not be able to do much with your report).

Klemet · 2021-07-02T15:47:37Z

Thank you, @mgallien ! You're right; it looks like I wasn't in the right place.

Since I'm unable to have any access to the logs, I'll try to see if I can replicate it before posting a report.

github-actions · 2021-07-30T16:57:39Z

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

github-actions · 2021-08-14T01:28:23Z

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!

TheOtherRealm · 2022-06-18T01:31:50Z

Please also note that there is config option that when enabled moves files to the trash instead of deleting them. With that option enabled you should be save in all situations. We discussed internally about enabling that option by default, but we're afraid that as soon as we enable that by default, people start to report bugs that their hard drive gets full. In most situation, the client behaves fine and does the correct thing. Introducing a dialog that would ask the user about every file that gets removed would annoy a lot of users, I guess. I know you could introduce another config option for that, but the goal should be to make the sync engine behave correct in all situations. After all, I use the client for a few years now and never had my files deleted.

Do you know the config key string for the option to move things to trash, or have a link to the documentation? It is still an an issues, or at least as of 2021-11-12 when my nextcloud instance decided to erase all of my documents.
Thanks

jabdoa2 · 2022-06-18T05:29:22Z

Please also note that there is config option that when enabled moves files to the trash instead of deleting them. With that option enabled you should be save in all situations. We discussed internally about enabling that option by default, but we're afraid that as soon as we enable that by default, people start to report bugs that their hard drive gets full. In most situation, the client behaves fine and does the correct thing. Introducing a dialog that would ask the user about every file that gets removed would annoy a lot of users, I guess. I know you could introduce another config option for that, but the goal should be to make the sync engine behave correct in all situations. After all, I use the client for a few years now and never had my files deleted.

Do you know the config key string for the option to move things to trash, or have a link to the documentation? It is still an an issues, or at least as of 2021-11-12 when my nextcloud instance decided to erase all of my documents. Thanks

This partially saved me. Partially, because there is some limit on folder size so that it did not work for all folders.

camilasan added the needs input label Apr 23, 2018

camilasan added needs info and removed needs input labels Apr 23, 2018

camilasan added help wanted bug labels Jun 4, 2018

Dennis1993 mentioned this issue Jan 18, 2019

Nextcloud Windows Client deletes files and folders #289

Closed

camilasan added Prio: high os: 🍎 macOS os: 🚪 Windows labels Mar 4, 2019

FlexW pushed a commit that referenced this issue Mar 19, 2021

Increase logging around file removal events

fcb0f2d

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913

FlexW mentioned this issue Mar 19, 2021

Increase logging around file removal events #3020

Merged

FlexW pushed a commit that referenced this issue Mar 19, 2021

Increase logging around file removal events

94c54c9

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913 Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>

FlexW pushed a commit that referenced this issue Mar 19, 2021

Increase logging around file removal events

bfcb375

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913 Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>

github-actions bot pushed a commit that referenced this issue Mar 22, 2021

Increase logging around file removal events

b1983d7

To better see what is going on when and if files are removed by the client. See also: #260, #1433, #2913 Signed-off-by: Felix Weilbach <felix.weilbach@nextcloud.com>

github-actions bot added the stale label May 6, 2021

github-actions bot removed the stale label May 12, 2021

github-actions bot removed the needs info label Jun 9, 2021

github-actions bot added the stale label Jul 30, 2021

github-actions bot closed this as completed Aug 14, 2021

kesselb mentioned this issue Aug 3, 2023

Detect external storage of type Local as unavailable when path is unmounted on system nextcloud/server#39706

Closed

Client deleted my files #260

Client deleted my files #260

Comments

Dennis1993 commented Apr 23, 2018 • edited Loading

camilasan commented Apr 23, 2018

michel-thomas commented Jun 3, 2018

michel-thomas commented Jun 4, 2018

Dennis1993 commented Jun 4, 2018

camilasan commented Jun 4, 2018

Dennis1993 commented Jun 21, 2018

Dennis1993 commented Nov 17, 2018

theroch commented Jan 5, 2019

theroch commented Jan 7, 2019 • edited Loading

theroch commented Jan 12, 2019

theroch commented Jan 14, 2019

theroch commented Feb 2, 2019

Fluotonic commented Feb 28, 2019 • edited Loading

hataos commented Jun 26, 2019 • edited Loading

MPCNextCloud commented Aug 2, 2019

j2g2rp commented Aug 17, 2019

Dennis1993 commented Aug 17, 2019

Reil commented Sep 17, 2019

camilasan commented Sep 18, 2019

Reil commented Sep 19, 2019

phsc84 commented Sep 19, 2019

ChagnonG commented Mar 19, 2021 • edited Loading

FlexW commented Mar 19, 2021

ChagnonG commented Mar 19, 2021

er-vin commented Mar 19, 2021

FlexW commented Mar 22, 2021

FlexW commented Mar 22, 2021

ChagnonG commented Mar 22, 2021

shurik-io commented Mar 30, 2021 • edited Loading

FlexW commented Mar 31, 2021

chainria commented Mar 31, 2021 • edited Loading

github-actions bot commented May 6, 2021

Klemet commented Jul 1, 2021 • edited Loading

mgallien commented Jul 2, 2021

Klemet commented Jul 2, 2021

github-actions bot commented Jul 30, 2021

github-actions bot commented Aug 14, 2021

TheOtherRealm commented Jun 18, 2022

jabdoa2 commented Jun 18, 2022

Dennis1993 commented Apr 23, 2018 •

edited

Loading

theroch commented Jan 7, 2019 •

edited

Loading

Fluotonic commented Feb 28, 2019 •

edited

Loading

hataos commented Jun 26, 2019 •

edited

Loading

ChagnonG commented Mar 19, 2021 •

edited

Loading

shurik-io commented Mar 30, 2021 •

edited

Loading

chainria commented Mar 31, 2021 •

edited

Loading

Klemet commented Jul 1, 2021 •

edited

Loading