Here's the new merge request: https://invent.kde.org/network/kio-extras/-/merge_requests/75

In D28745#677439, @ngraham wrote:

Is this unblocked now that https://invent.kde.org/frameworks/solid/-/merge_requests/19 has been merged?

I think I have the Solid part done, but as I don't know this code well, I'd be grateful if someone more advanced on the subject checked it.

In D28745#676566, @sitter wrote:

In D28745#676452, @marcingu wrote:

!PING.
I need help from someone with good understanding of Solid to continue.

I'm don't know how to determinate if StorageAccess device is encrypted or not. I wanted to use StorageVolume::usage, but it's not available for all types of devices and doesn't equal encrypted for LUKS encrypted volumes.

At a glance the problem here is actually that depending on the setup the mounted volume isn't necessarily the encrypted volume. e.g. if you make a LUKS encrypted btrfs on /dev/sda1 then sda1 is type LUKS encrypted, but to actually use it that device gets decrypted and mapped into a different name /dev/mapper/luks-123 which is type btrfs and not encrypted. It is only the mapped one that gets mounted which is why the encryption context gets lost along the way.

I'm afraid this will need some adjustment in solid because currently we don't carry that information anywhere that I can see. It is however in the data of udiks2 behind the scenes (dbus property org.freedesktop.UDisks2.Block.CryptoBackingDevice which is a dbuspath of the encrypted backing object) so it should be readily available, just needs putting somewhere in solid. This is also represented in the sysfs through a slave relationship between the two block devices, but I'm guessing using that over udiks2 isn't nearly as portable.
Where to put it I don't really know, probably a new method on one of the interface classes CryptoBackingUDI which returns the UDI representing the backing device.

!PING.

How do we check if file access is encrypted using Solid? Do we need new property/method in StorageAccess?

!PING.
I need help from someone with good understanding of Solid to continue.

In D28745#676321, @bruns wrote:

In D28745#676320, @marcingu wrote:

In D28745#676317, @bruns wrote:

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

The whole block can never return true, so it should just be removed, along with all its dependencies.

I tested it once more and it returns true when it should, as expected. What makes you think it doesn't?

Even worse, its almost random:

udi = '/org/kde/fstab///pebbles/foo:/mnt'
  parent = '/org/kde/fstab'  (string)
  vendor = 'pebbles'  (string)
  product = 'foo:/mnt'  (string)
  description = 'foo:/mnt on pebbles'  (string)
  icon = 'network-server'  (string)
  StorageAccess.accessible = false  (bool)
  StorageAccess.filePath = '/mnt'  (string)
  StorageAccess.ignored = false  (bool)
  NetworkShare.type = 'Cifs'  (0x2)  (enum)
  NetworkShare.url = 'smb://pebbles/foo:/mnt'  (string)

if (device.is<Solid::StorageVolume>()) -> false, though it should be cached

udi = '/org/freedesktop/UDisks2/block_devices/dm_2d2'
  parent = '/'  (string)
  vendor = ''  (string)
  product = ''  (string)
  description = '100,0 GiB Hard Drive'  (string)
  icon = 'drive-harddisk-root'  (string)
  Block.major = 254  (0xfe)  (int)
  Block.minor = 2  (0x2)  (int)
  Block.device = '/dev/dm-2'  (string)
  StorageAccess.accessible = true  (bool)
  StorageAccess.filePath = '/'  (string)
  StorageAccess.ignored = true  (bool)
  StorageVolume.ignored = false  (bool)
  StorageVolume.usage = 'FileSystem'  (0x2)  (enum)
  StorageVolume.fsType = 'btrfs'  (string)
  StorageVolume.label = ''  (string)
  StorageVolume.uuid = '5832ebfa-bf02-40d2-bdc7-90403b207b62'  (string)
  StorageVolume.size = 107374182400  (0x1900000000)  (qulonglong)

This is an LUKS encrypted volume so should not be cached ...

In D28745#676317, @bruns wrote:

In D28745#676313, @marcingu wrote:

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

Question:
This code won't save thumbnail for file on any device that isn't StorageVolume or is StorageVolume with usage UsageType::Encrypded.

The whole block can never return true, so it should just be removed, along with all its dependencies.

Ping!
I'm remanding about question early, because I could do much more work if I get to do it on weekend.

In D28745#676303, @bruns wrote:

Second, I have asked for a full context diff, or even better moving this to invent.kde.org, but @marcingu keeps ignoring this.

Renaming "deviceIdUnset" to "s_deviceIdUnset"

Moving allowCache check, so it's done only if thumbnail was created.

Setting canonical path as value of hadFirstThumbnail

Removing unnecessary includes

Using special value instead of 0 as unset m_thumbnailDirDeviceId.
Changing ifdef checks for Q_OS_WIN for consistency.
Moving ifdev check into sharesFilesystemWithThumbRoot, to reduce number of preprocessor directives.

Skipping usage of POSIX functions and types on Windows

Adding path to error logs

Using solid for getting Device

I made merge request for storageAccessFromPath: https://invent.kde.org/frameworks/solid/-/merge_requests/8

In D28745#675709, @bruns wrote:

In D28745#675698, @marcingu wrote:

How often do I have to repeat the thumbnailer has to use the canonical path anyway? Please use that.

storageAccessFromPath converts given path into canonical. I figured it should do so anyway, so I'm not doing it again here.

And thats wrong. You need the canonical path in the thumbnailer itself.

How often do I have to repeat the thumbnailer has to use the canonical path anyway? Please use that.

Ok, so far I have implemented Solid::Device::storageAccessFromPath by talking all StorageAccess devices, going though all of them and and returning proper one.
code:

Solid::Device Solid::Device::storageAccessFromPath(const QString &path)
{
    // TODO check if symlinks are in the path
    QFileInfo fileInfo = QFileInfo(path);
    if (!fileInfo.exists()) {
        //TODO error handling
    }
    QSet<QString> checked; //To avoid weird infinete loops
    checked.insert(fileInfo.path());
    while (fileInfo.isSymLink()) {
        fileInfo = QFileInfo(fileInfo.symLinkTarget());
        if (checked.contains(fileInfo.path())) {
            //TODO error handling
        }
        checked.insert(fileInfo.path());
    }
    QDir dir = fileInfo.dir();
    QString canonPath = dir.canonicalPath();
    QList<Device> list = Solid::Device::listFromType(DeviceInterface::Type::StorageAccess);
    Device match;
    int match_length = 0;
    for (Device device: list) {
        StorageAccess *storageAccess = device.as<StorageAccess>();
        if (canonPath.startsWith(storageAccess->filePath()) && storageAccess->filePath().size() > match_length) {
            match_length = storageAccess->filePath().size();
            match = device;
        }
    }
    return match;
}

Ok, so, what I want to do now is to create static method findByPath which is going to return Solid::StorageVolume instance (is there a case in which we can expect something different than StorageVolume?).

Ping! I'm not able to continue without help of someone who knows Solid::Device well.

I tried to research Solid using api.kde.org (https://api.kde.org/frameworks/solid/html/classSolid_1_1Device.html, https://api.kde.org/frameworks/solid/html/classSolid_1_1StorageVolume.html) and looking for usages of both Solid::Device and Solid::StorageVolume in code but I'm not able to get StorageVolume instance for given file/directory. Could someone help me with that?

PING!
Is current code fine or should we get rid of KMountPoint completely somehow?

Moving check for sharing filesystem with thumbroot into new method.

Unless there's way to get rid of KMountPoint completely, this should reduce number of calls to minimum.

Limiting usage of KMountPoint and lstat to max once per directory.

Review fixes

I improved check if file is on the same filesystem as thumbnails cache, but don't know if we can get rid of KMountPoint completely.

Checking if file is on the same filesystem as thumbnails cache directory using lstsat

Ok, Thanks! I'll check it this weekend.

In D28745#648036, @meven wrote:

This is gonna have an hefty toll on perf as it will add a getmntent syscall to every thumbnail generation.
Using Solid::Device::listFromType would leverage Solid always up-to-date (using events rather thane sysalls) device cache.
I am not sure in the end this is preferable though.

Removing extra whitespaces

Removing extra whitespaces

Moving boolean variables to the front of logic statement.

Review fixes

Review fixes