Bug 290755 - Solid::NetworkShare detects only shares mounted through fstab backend
Summary: Solid::NetworkShare detects only shares mounted through fstab backend
Status: RESOLVED FIXED
Alias: None
Product: solid
Classification: Frameworks and Libraries
Component: libsolid (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR major
Target Milestone: ---
Assignee: Alex Fiestas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-05 23:31 UTC by Elias Probst
Modified: 2012-03-17 23:10 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elias Probst 2012-01-05 23:31:52 UTC
Version:           unspecified (using Devel) 
OS:                Linux

When unmounting a volume which isn't provided through fstab but has been manually mounted or through AutoFS, Nepomuk deletes all indexed data of files from this volume because it wasn't detected as removable storage previously by Solid and Nepomuk relies on Solid's removable storage detection.

Reproducible: Always

Steps to Reproduce:
This probably happens in other similar setups, too. I'll outline here my setup.
1. Define an NFS volume in AutoFS
2. Make AutoFS mount the defined NFS volume
3. Configure Nepomuk to index data on this NFS volume
4. Unmount the NFS volume (e.g. disconnect network)
5. Wait some time until Nepomuk's filewatch service kicks in and starts cleaning up data of non-existent files

Actual Results:  
a) When mounting the NFS volume, there's no popup by Nepomuk, which asks, whether to index the data on this removable storage (this can be worked around by manually configuring Nepomuk to index this mountpoint).

b) Nepomuk deletes all information related to files on the unmounted NFS volumes  when the filewatch service looks up whether the files on this volume do still exist

Expected Results:  
a) Nepomuk should ask the user whether to index data on the NFS volume when it is mounted

b) Nepomuk shouldn't delete information of files which reside on the unmounted NFS volume

Although this bug mentions Nepomuk all the time (where the actual critical deletion of information happens), this is caused by Solid as it only handles NFS volumes which are defined in /etc/fstab.

Any other way to use NFS volumes (mounted manually/mounted through AutoFS or any other mechanism) is not handled at all.

Solid should query the Kernel (or any other suitable tool/interface which provides the necessary information) of currently mounted volumes and also take them into account when listing removable media.
Comment 1 Elias Probst 2012-01-29 16:49:29 UTC
Changing the title, as after some discussions with lamarque on #solid, it became clear that the described problem wasn't fully understood.

How to reproduce the problem:
1. Look at the output of "solid-hardware query 'IS StorageAccess'"
2. Add an NFS/CIFS/… share to /etc/fstab
3. Look again at the output of "solid-hardware query 'IS StorageAccess'"
4. Mount an NFS/CIFS/… share which is not listed in /etc/fstab manually or through a mechanism like AutoFS or amd
5. Look again at the output of "solid-hardware query 'IS StorageAccess'"

What's the problem:
1. Lists no NFS/CIFS/… shares → OK
3. Lists the NFS/CIFS/… shares added to /etc/fstab → OK
5. Doesn't list the NFS/CIFS/… share which wasn't mounted by being listed in /etc/fstab → NOT OK

This results in several issues:
- Such NFS/CIFS/… shares aren't listed in the places panel of the file dialog, Dolphin, etc.
- Nepomuk doesn't ask the user (as it does when plugging in a USB storage device) whether to index data on this device/share
- the initially described issue, that only NFS/CIFS/… shares listed in /etc/fstab are recognized by Nepomuk as removable storage, thus Nepomuk deletes related data from the Nepomuk repository when the share is unmounted and the filewatcher service doesn't find the files of the share anymore.


Why does Nepomuk delete such data and why is this not Nepomuk's, but Solid's fault?
- Nepomuk relies on Solid to find out, whether a file is stored on a removable device or not by comparing the file's path to the paths provided by Solid's list of removable storage
- Nepomuk runs periodically the "filewatch" service to remove outdated data of deleted files/files which can't be found anymore by Nepomuk




An example to demonstrate this issue:
- Manually mount your mediaserver's NFS share to /media/Multimedia
- Configure Nepomuk to index the path /media/Multimedia
- Wait for Nepomuk to finish the indexing
- Query Nepomuk (e.g. in Dolphin's search or an application like Bangarang) for some data of files stored on /media/Multimedia → SUCCESS
- Unmount the NFS share from /media/Multimedia
- Wait for Nepomuk's 'filewatcher' service to kick in (or start it manually via D-Bus (org.kde.nepomuk.ServiceManager → startService: nepomukfilewatch)
- Wait for the 'filewatcher' service to finish
- Query Dolphin/Bangarang/… again for data on the NFS share → No data will be found

Why does this happen?
- Before indexing a file, Nepomuk queries Solid for removable devices and determines, whether the path of the file resides on a mounted removable device.
- When querying Solid for removable devices, the share mounted at /media/Multimedia won't be included, so Nepomuk assumes it is just a regular file on local storage
- When Nepomuk's filewatcher cleans up records of deleted files and the share is unmounted, it also deletes the record of any file stored on /media/Multimedia as  this records don't have a flag set which would mark them as "removable"


How should this bug be fixed?
Solid::NetworkShare should not only query /etc/fstab for NFS/CIFS/… shares, but also the Kernel or /proc/mounts for mounted shares.
While the entries in /etc/fstab are static and picked up by solid as soon as they're listed in /etc/fstab (even when they're unmounted), manual/AutoFS/amd mounts will only be listed as soon as they're mounted.
Comment 2 Mario Bensi 2012-02-28 15:24:50 UTC
Git commit c45ecdbbd14465b7afd5779d5bd7b41a2b97efe4 by Mario Bensi.
Committed on 28/02/2012 at 16:12.
Pushed by bensi into branch 'KDE/4.8'.

Combined handling of fstab and mtab, improved caching

This patch reworks several aspects of the fstab and mtab handling.
1. Most importantly, it takes the union of fstab and mtab to create a
list of available shares.
2. Mtab is cached and keyed by share name, as fstab already is
3. FstabManager serves as a central dispatcher for mtab/fstabChanged
signals. Caches are invalidated, and recreated when needed.
4. Caches and valid flags are members of the FstabHandling class. Valid
flags are needed to differentiate between "empty and valid" and invalid
caches.

REVIEW: 103956
REVIEW: 103957

M  +6    -0    solid/solid/backends/fstab/fstabdevice.cpp
M  +7    -0    solid/solid/backends/fstab/fstabdevice.h
M  +55   -28   solid/solid/backends/fstab/fstabhandling.cpp
M  +20   -1    solid/solid/backends/fstab/fstabhandling.h
M  +41   -15   solid/solid/backends/fstab/fstabmanager.cpp
M  +5    -0    solid/solid/backends/fstab/fstabmanager.h
M  +22   -26   solid/solid/backends/fstab/fstabstorageaccess.cpp
M  +3    -2    solid/solid/backends/fstab/fstabstorageaccess.h

http://commits.kde.org/kdelibs/c45ecdbbd14465b7afd5779d5bd7b41a2b97efe4
Comment 3 Elias Probst 2012-03-13 21:16:15 UTC
Thanks a thousand times for implementing this - this was one of my personally most-hated bugs :)

One tiny little issue I found:
I need to restart Dolphin to have an NFS share show up in the places panel. Is there probably the notification missing when a new mtab-mount is detected which is then used by Dolphin to update its places panel?
When an NFS share is unmounted, it disappears instantly from the places panel, so this works.

If you think this is a Dolphin bug, please close this bug again.

Running KDE 4.8.1 now here.
Comment 4 Elias Probst 2012-03-17 23:10:09 UTC
(In reply to comment #3)
> I need to restart Dolphin to have an NFS share show up in the places panel.
> Is there probably the notification missing when a new mtab-mount is detected
> which is then used by Dolphin to update its places panel?
> When an NFS share is unmounted, it disappears instantly from the places
> panel, so this works.

Looks like this has been fixed (bug#293914), so closing this bug as FIXED.