Bug 452924

Addendum: 
This does not only affect images, the "Details" pane in file properties does not show up for ANY file on remote locations

Same problem under KDE Neon Unstable Edition with
SOFTWARE/OS VERSIONS
Dolphin: 22.07.70
KDE Plasma Version: 5.24.80
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.3

Yeah, the EXIF metadata is extracted using Baloo, and Baloo doesn't index network locations.

I guess we could fall back to using kfilemetadata here and read it on the fly.

(In reply to Nate Graham from comment #3)
> Yeah, the EXIF metadata is extracted using Baloo, and Baloo doesn't index
> network locations.
> 
> I guess we could fall back to using kfilemetadata here and read it on the
> fly.

Yes, but it does not only affect EXIF, it affects ALL Metadata. The "Details" tab in file properties does not even show up for remote locations

Besides that, reading metadata on the fly would be a much better process IMO than only having previously indexed metadata available.
It allows for greater flexibility, besides the fact that some people deactivate or uninstall baloo entirely

Same here - I think it is due to extended attributes not correctly assigned. 

I thought this is happening because my network file server (Synology NAS) might not support xattr data. But I experimented quite a lot and it turns out the server does. I checked the xattr state of files I copied to the server and it turns out they are there. 

Copying the files  in dolphin to the network share and then moving the file back results in a loss of all file tags which are, as I understand saved as extended file attributes. 

Here's parts of my post on reddit: 

-----------------------------
Hi!

As I understand the KDE file tags that can be applied by dolphin get written into the extended attributes of the tagged files. So that's fine and works most of the times...

But it seems that dolphin loses the ability to read or assign tags in any mounted network folder - though the network server uses btrfs as well and the shares (I tried nfs and cifs/samba mounting) should support unix attributes.

So do I need additional mount options to make KDE tags "stick" in network shares?

I do not seem to have the same problem with local mounts....

Anyone? Thanks!

Cheers, p.

p.s.: Btw... - the context menu in dolphin still shows the "Add tag" entry - but adding tags in the mounted folders doesn't do anything... 
-------------------------------------------- 

p.

So I do not think it's only about reading the files metadata - moving the file to the network share and back loses the metadata!

(In reply to piedro from comment #7)
> So I do not think it's only about reading the files metadata - moving the
> file to the network share and back loses the metadata!

What metadata are you talking about specifically? Tags and comments are preserved on my system, even if I move the file to the network and back.

Exactly these - tags and comments... 

Here's what happens: 

- I take a simple test.jpg and add the tag "testfile" and the comment "this is just a test file". 

So now dolphin shows me 
- all the EXIF metadata of the jpg 
- the tag "testfile" 
- the comment "this is just a test file" 

Now I move the file to my media folder which is a network resource on a Synology Diskstation (I tried this with samba and  nfs shares).

Dolphin's side pane shows me 
- no EXIF data 
- no tags 
- no comment 

Now I move the test file back to it's orignal location. 
- Exif data is shown 
- no tag
- no comment 

This does not happen with local mounts (obviously these are btrfs, xfs, and ext4 mounts, so these are no network systems obviously) 

So effectively I lose my comment and my tags by moving the file via a network share... :-(

I've tested again with multiple files. Tags and comments are not lost for me when moving or copying to Network and back. Of course I cannot see them when the file is on the network, but after the file is back on local storage it shows again as expected. Maybe a different problem on your end?

Hmmm... 

Checking the file on the server with 

lsattr test.jpg gives me 

--------c--------- test.jpg 

So there are extended attributes on the file... - maybe it's up to the mount options... 

May I ask about the filesystem and mount options you are using to make this work?

NFS with default options (except for noatime) on client and server, btrfs on local storage. After having added a tag and comment to a new test file and checked with lasattr:
---------------------- ./test
Adding tags and comments doesn't seems to affect these attributes.
The "--------c---------" means your file is compressed by the file system

I use Dolphin 22.04 on Arch Linux.
'Details' tab is also missing in the properties of files stored in a ntfs partition mounted
with ntfs-3g driver. 'Details' tab is present if the same partition is mounted with ntfs3 driver instead.

Worth noting that before a recent update to kde/dolphin, metadata display on network share worked fine, so this is a fairly recent regression/bug.

*** Bug 453500 has been marked as a duplicate of this bug. ***

*** Bug 453677 has been marked as a duplicate of this bug. ***

Just want to add that the context menu (right click) in network folders is different than the one that shows on loacl folders. 

For example if I cut a file or folder than, on a local fodler, I get the option to paste it into the open folder via context menu. 
If I try to paste the same file or folder into a network folder I do not get the context menu entry for pasting. 

I do not know if this behavior is connected - but I think it's worth mentioning here.

I'd noticed that thumbnailing wasn't working for network shares either, but that seems to have resolved itself. 

Saw an update today, unfortunately the issue is still present with KDE 5.94.0, Qt 5.15.4, Plasma 5.24.5.

*** Bug 455110 has been marked as a duplicate of this bug. ***

I guess that this bug is a consequence of the different treatment for network locations introduced with a previous Frameworks version (5.93?). It is still present with Frameworks 5.95.

(In reply to Patrick Silva from comment #13)
> I use Dolphin 22.04 on Arch Linux.
> 'Details' tab is also missing in the properties of files stored in a ntfs
> partition mounted
> with ntfs-3g driver. 'Details' tab is present if the same partition is
> mounted with ntfs3 driver instead.

This bug persists with Dolphin 22.08.1 on Arch Linux.

Created attachment 153479 [details]
kio patch for nfs shares

This behavior comes from the package kio, file src/core/kfileitem.cpp:
...
bool KFileItemPrivate::isSlow() const
{
    if (m_slow == SlowUnknown) {
        const QString path = localPath();
        if (!path.isEmpty()) {
            const KFileSystemType::Type fsType = KFileSystemType::fileSystemType(path);
            m_slow = (fsType == KFileSystemType::Nfs || fsType == KFileSystemType::Smb) ? Slow : Fast;
        } else {
            m_slow = Slow;
        }
    }
    return m_slow == Slow;
}
...

Line 829: m_slow = (fsType == KFileSystemType::Nfs || fsType == KFileSystemType::Smb) ? Slow : Fast;

This patch removes nfs from the condition.

Best regards
Alex

I con confirm the bug. "Details" pane in file properties does not show up for ANY file on SMB shares.

There is another problem that might be related to this bug?

You cannot tag files on SMB shares.
=> https://www.reddit.com/r/kde/comments/103wujq/tagging_files_on_network_shares_smb/

Maybe also ...
    https://bugs.kde.org/show_bug.cgi?id=341288#c3

Can confirm this bug still exists.

SMB? This bug exists.
NFS? This bug exists.
External USB? Normal behavior.
Local drive? Normal behavior.

KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9

Probably relevant but far from done: https://invent.kde.org/system/dolphin/-/merge_requests/522

This bug also applies to both Debian stable (bookworm) and testing (trixie), as well as the current Kubuntu Neon LTS  at this time. 

In the past this bug has been fixed by disabling File Search & indexing in systemsettings5/File Search but that no longer works. Nor does 'balooctl disable' and rebooting help. Increasing the size of "Skip previews for remote files above" to some very high number in the Dolphin/Configure/General/Previews tab also doesn't help. I've tried installing several thumbnailer packages, e.g. kdegraphics-thumbnailers, and related KDE packages, but none of them seem to help. konqueror (which was the best file manager ever IMO back in KDE 3.x days) behaves the same way as dolphin.

I can go to the Context Menu tab of dolphin/Configure, click on Download New Services, search for 'mediainfo' and install the Mediainfo Service Menu (https://store.kde.org/p/1418250). This enables me to right-click on a file on a LAN and choose mediainfo to get the metadata from images & multimedia files, but this is somewhat cumbersome, and seeing metadata on the dolphin Properties/Details tab, F11 Information field or the dolphin file preview on LAN shares used to work fine (sometimes with a little tweaking to baloo) a few years ago.

Inspired by Alex's patch, but not wanting to re-compile kio after every update, I wrote a temporary fix for this issue using LD_PRELOAD, which only requires a single compilation and should work as kio/Dolphin updates. It simply intercepts statfs() syscalls and returns a fake filesystem type of "ext4" for NFS filesystems. KFileItemPrivate::isSlow() calls KFileSystemType::fileSystemType() which calls statfs().

https://gist.github.com/DownrightNifty/fbfdf50cac60c6d973ebef10438d7ee5

It seems this could be resolved upstream by allowing the user to choose which remote filesystems are designated as "slow".