Your message dated Sun, 08 Oct 2023 02:22:11 +0200
with message-id <3309717.CA4L6bvzst@tuxin>
and subject line Re: Bug#996924: nextcloud-desktop: deletes dirs on the server
although they're still here locally
has caused the Debian Bug report #996924,
regarding nextcloud-desktop: deletes dirs on the server although they're still
here locally
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
996924: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996924
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: nextcloud-desktop
Version: 3.1.1-2+deb11u1
Severity: important
>From time to time, whole directories get erased from the server for no
reason. I've seen it happen a few times already, but not early enough
to be able to catch logs. So far I've been lucky enough to be able to
restore from backups, but it's not something that I can afford to see
happen again.
In my case, the client sent a DELETE request for a directory that
hadn't been deleted locally. The
~/.local/share/Nextcloud/Documents_sync.log file shows it:
12:27:42||TEMP|INST_REMOVE|Up|1633813324|61620350e2e1d|0|06377550ocptyqgkbgt0|4||204|0|0||||
At the same time, the server log shows the corresponding request:
[REDACTED] [17/Oct/2021:14:27:42 +0200] "DELETE
/remote.php/dav/files/DetR/Documents/TEMP HTTP/1.1" 204 609 "-" "Mozilla/5.0
(Linux) mirall/3.1.1-2+deb11u1 (Nextcloud)"
So obviously, on all other clients using that shared Documents
directory, the TEMP directory is deleted. It's still present locally,
but there's a discrepancy with the server, and that discrepancy is not
always resolved in the right direction: sometimes in the past the
directory was restored from the local version and eventually
re-uploaded then re-synced to other clients, but other times the local
version was deleted too, in which case the directory is completely
lost.
This is really major, and the fact that it happens "rarely" (although
a couple of times a year for me) doesn't make it less grave.
For reference the server runs 21.0.0, but I've seen this bug happen
with previous versions too, and I don't think the bug is server-side.
I'm fully willing to help provide more info if instructed how, but
note that the bug is unpredictable to me.
It may be relevant that my Documents share is about 500 GB in size,
with about 300k files.
Please advise.
-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nextcloud-desktop depends on:
ii libc6 2.31-13+deb11u2
ii libcloudproviders0 0.3.0-3
ii libgcc-s1 10.2.1-6
ii libglib2.0-0 2.66.8-1
ii libnextcloudsync0 3.1.1-2+deb11u1
ii libqt5core5a 5.15.2+dfsg-9
ii libqt5dbus5 5.15.2+dfsg-9
ii libqt5gui5 5.15.2+dfsg-9
ii libqt5keychain1 0.10.0-1
ii libqt5network5 5.15.2+dfsg-9
ii libqt5qml5 5.15.2+dfsg-6
ii libqt5quick5 5.15.2+dfsg-6
ii libqt5quickcontrols2-5 5.15.2+dfsg-2
ii libqt5sql5-sqlite 5.15.2+dfsg-9
ii libqt5svg5 5.15.2-3
ii libqt5webenginecore5 5.15.2+dfsg-3
ii libqt5webenginewidgets5 5.15.2+dfsg-3
ii libqt5webkit5 5.212.0~alpha4-11
ii libqt5widgets5 5.15.2+dfsg-9
ii libstdc++6 10.2.1-6
ii nextcloud-desktop-common 3.1.1-2+deb11u1
ii nextcloud-desktop-l10n 3.1.1-2+deb11u1
ii qml-module-qtgraphicaleffects 5.15.2-2
ii qml-module-qtqml-models2 5.15.2+dfsg-6
ii qml-module-qtquick-controls2 5.15.2+dfsg-2
ii qml-module-qtquick-layouts 5.15.2+dfsg-6
ii qml-module-qtquick-window2 5.15.2+dfsg-6
ii qml-module-qtquick2 5.15.2+dfsg-6
Versions of packages nextcloud-desktop recommends:
ii nextcloud-desktop-doc 3.1.1-2+deb11u1
nextcloud-desktop suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hey,
we don't get any new info if the issue is reported upstream. Close this bug
report, as it is not helpful to keep it open for years without any resonance.
If we had an upstream bug we could track the status.
Regards,
hefee
--
On Montag, 22. November 2021 14:36:17 CEST you wrote:
> Control: tags -1 +upstream
>
> Hey,
>
> It would be helpful, if you can try a newer version from Debian unstable, if
> you see the same behaviour or if is been fixed meanwhile.
> Anyways this is an upstream bug. So you should get in contact with nextcloud
> directly:
>
> https://github.com/nextcloud/desktop/issues
>
> If you find a corresponding bug or create a new one please leave a message
> here, so we can update the metadata for this bug.
>
> Regards,
>
> hefee
>
> --
>
> > From time to time, whole directories get erased from the server for no
> > reason. I've seen it happen a few times already, but not early enough
> > to be able to catch logs. So far I've been lucky enough to be able to
> > restore from backups, but it's not something that I can afford to see
> > happen again.
> >
> > In my case, the client sent a DELETE request for a directory that
> > hadn't been deleted locally. The
> > ~/.local/share/Nextcloud/Documents_sync.log file shows it:
> >
> > 12:27:42||TEMP|INST_REMOVE|Up|1633813324|61620350e2e1d|0|06377550ocptyqgkb
> > gt 0|4||204|0|0||||
> >
> > At the same time, the server log shows the corresponding request:
> >
> > [REDACTED] [17/Oct/2021:14:27:42 +0200] "DELETE
> > /remote.php/dav/files/DetR/Documents/TEMP HTTP/1.1" 204 609 "-"
> > "Mozilla/5.0 (Linux) mirall/3.1.1-2+deb11u1 (Nextcloud)"
> >
> > So obviously, on all other clients using that shared Documents
> > directory, the TEMP directory is deleted. It's still present locally,
> > but there's a discrepancy with the server, and that discrepancy is not
> > always resolved in the right direction: sometimes in the past the
> > directory was restored from the local version and eventually
> > re-uploaded then re-synced to other clients, but other times the local
> > version was deleted too, in which case the directory is completely
> > lost.
> >
> > This is really major, and the fact that it happens "rarely" (although
> > a couple of times a year for me) doesn't make it less grave.
> >
> > For reference the server runs 21.0.0, but I've seen this bug happen
> > with previous versions too, and I don't think the bug is server-side.
> >
> > I'm fully willing to help provide more info if instructed how, but
> > note that the bug is unpredictable to me.
> >
> > It may be relevant that my Documents share is about 500 GB in size,
> > with about 300k files.
> >
> > Please advise.
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
