Bug 414178

Summary: Deleting all contacts deletes entire /home/user/
Product: [Frameworks and Libraries] Akonadi Reporter: Anselm Wagner <anselm.wagner>
Component: Contacts resourceAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED WORKSFORME    
Severity: critical CC: anselm.wagner, freitag, Martin, nate
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:

Description Anselm Wagner 2019-11-15 14:56:44 UTC
In kontact I deleted all my personal contacts via the GUI. Aferwards my personal home folder /home/user/ was reset to default with all my personal files gone.

STEPS TO REPRODUCE
1. I did a right click in kontact/adressbook on "personal contacts"
2. Dolphin would not open up anymore. OwnCloud started to resync everything.
3. I did a restart.

OBSERVED RESULT
My entire home/user/ folder was reset to default.
My /home partition is shown to practically empty now.
All my files, photos, videos, texts, configurations are gone.

EXPECTED RESULT
Only my contacts should be deleted, nothing else.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma:
Linux 5.3.11-arch1-1
(available in About System)
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2

ADDITIONAL INFORMATION
kontact Version: 5.12.3
The / and the /home partition reside on a single ssd-drive, which has btrfs as a file system.
btrfs-progs v5.3.1

The following is my fstab for this ssd:
$ cat /etc/fstab 
# 
# /etc/fstab: static file system information
#
# <file system> <dir>   <type>  <options>       <dump>  <pass>
# /dev/sda1
UUID=36b2126b-9ce8-49be-99d2-2261fd487a5c       /               btrfs           rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/        0 0

# /dev/sda3
UUID=1074c412-69ff-45ef-85d7-69d41888c57d       /home           btrfs           rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/        0 0

# /dev/sda2
UUID=4cc13057-a5ee-4f19-a4d9-585ab3184867       none            swap            defaults                                                0 0

I would be very glad to provide any information that might proof useful.
Comment 1 Volker Krause 2019-11-17 11:12:48 UTC
Git commit e3e0ee0ddc82bf6a34ebe93ed6c5c881f412ddc2 by Volker Krause.
Committed on 17/11/2019 at 11:12.
Pushed by vkrause into branch 'release/19.12'.

Sanity-check collection path before performing recursive deletion

Summary:
There is a error paths in directoryForCollection() which might give us
an empty string here, which is then interpreted as the current working
directory.

Reviewers: mlaurent

Reviewed By: mlaurent

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D25346

M  +6    -2    resources/contacts/contactsresource.cpp

https://commits.kde.org/kdepim-runtime/e3e0ee0ddc82bf6a34ebe93ed6c5c881f412ddc2
Comment 2 Nate Graham 2019-11-19 16:59:33 UTC
So this is possible? Yikes!
Comment 3 Klaas Freitag 2020-06-13 20:40:56 UTC
I read that by chance, and have a question about one sentence in your initial description: You wrote "ownCloud started to resync everything."

Being involved with ownClouds sync algorithm I know that there are several options to get catastrophic results such as removing everything (Syncing means that removes are also propagated). Not that Akonadi is a red herring here!?

Can you please describe a bit more in detail what role the ownCloud sync played in this scenario? Are you, for example, syncing your entire home dir? Could you check if you still have the sync log file .owncloudsync.log in your sync directory?
Comment 4 Anselm Wagner 2020-06-23 12:23:13 UTC
The ownCloud Client syncronizes a directory inside my home directory. On the ownCloud server, there was nothing deleted. So this ownCloud-directory inside of my home directory was the only directory, that was not deleted.

I do not see a .owncloudsync.log file. The server I use, is from my University: Sciebo-Campus cloud (https://sciebo.de/en/)

The only hidden files present in my ownCloud directory are:
._sync_XXXXXXXXXXX.db
.sync_XXXXXXXXXXX.db
.sync_XXXXXXXXXXX.db-shm
.sync_XXXXXXXXXXX.db-wal

could any of these files be of any help?
Comment 5 Martin Steigerwald 2020-06-23 12:35:48 UTC
Dear Anselm, thank you for that important bug report. Does the fix from comment #1 by Volker Krause actually fix the issue?

If its still not fixed please reply and set to REPORTED again, if you cannot set this, let me know and I will do it. Also please set the version you tested with, preferably 5.14.x aka 20.04 or at least 19.12, you see the version by using akonadictl --version

IMPORTANT: Please make sure that you test this with a user you created for testing to avoid loosing valuable data.
Comment 6 Bug Janitor Service 2020-07-08 04:33:08 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Bug Janitor Service 2020-07-23 04:33:09 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!