Thanks for the report, I could reproduce the issue.

It does show the custom icon here (using current master), but only after either pressing F5 or changing the URL and going back. Before that, a generic icon (a sheet of paper, not even a folder icon) is shown here. Looks like it might be related to bug 288691.

BTW, the new view engine is not based on QML.

It seems that it' not even necessary to change the icon in the "Properties" dialog - pressing "OK" without any change is enough, at least in master (see bug 288921).

Git commit bb192503cac22b08f0dd0c82e6bf059be8f98265 by Peter Penz.
Committed on 16/12/2011 at 22:01.
Pushed by ppenz into branch 'master'.

Update the roles if items have been changed

The code "// TODO..." in slotItemsChanged() obviously was not
sufficient ;-)

BUG: 288691
BUG: 288824
BUG: 288921
FIXED-IN: 4.8.0

M  +42   -38   dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp
M  +23   -0    dolphin/src/kitemviews/kfileitemmodelrolesupdater.h

http://commits.kde.org/kde-baseapps/bb192503cac22b08f0dd0c82e6bf059be8f98265

Sorry, need to re-open it.
It works now for directories in my home directory, but not for directories on my NFS share, where it used to work before (4.7.3 and earlier).

See the attached screenshot, which shows the directory view of Dolphin and the properties dialog of the "Bilder" directory, which has a custom icon assigned.
The custom icon is shown in the directory properties, but not in Dolphin.

The content of the .directory file of the "Bilder" directory is:
[Desktop Entry]
Icon=folder-image

Created attachment 67102 [details]
Screenshot showing directory and directory properties with custom icon.

See the previous comment.

Forgot to add information about the used KDE version.
Running now Dolphin 1.99 on KDE 4.7.95 (4.8.0 RC1), using Qt 4.7.4.

I've just noticed, that the behaviour described in comment#6 also applies to the KDE Filedialog (custom icons shown in /home, but not on NFS share).

@Peter: Are you able to identify, whether this is a general KIO KFile bug or a bug in both: Dolphin and KIO KFile?

The KDE file dialog uses no code from Dolphin, so if your issue occurs there it seems to be a bug in kio/kfile... - I did not check the code there (I'd need to get familiar with this part first and don't have the time for it at the moment :-( ) but probably it is NFS related.

I've same problem since upgrade to KDE 4.7.4 (with 4.7.3 all is OK)
Peter, We need to create an other report related to KIO or KFILE to fix the problem ?

@Chassagneux: I currently have no access to my 4.7.4 environment to verify this (I'm in the office at the moment) - anyhow if this is a general issue introduced with 4.7.4 even with the normal file://-URLs then it is no Dolphin issue (nothing has been changed in Dolphin between 4.7.4 + 4.7.3 in this area). So a new bug should be reported in this case - I'd say kio should be used as group.

I find the issue : 

http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=02b7eb5d92daae4373e7d38d2d952a688bd42079

But I don't know why for a NFS share with a 1Gb/s bandwitch is considered as a slow file-system ...

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

@Chassagneux: Thanks for the pointer. I did not have a closer look but it seems that this commit is the root-cause why no custom icons are shown anymore an filesystems that are considered as "slow".

However I'm leaving this issue open for Dolphin: The new view-engine allows to read slow meta-data step by step, so that the user interface won't get blocked. So it might be an option to read the .directory file still in this case.

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

No promises regarding a schedule, but in bug 178678 David Faure proposes a solution in kdelibs that should make it possible to reenable the custom icons for "slow" filesystems without blocking the user interface.

Hi,

I'm working on a FUSE fs notifyfs, which is aimed to replace gamin. I'm thinking also to make it handle .directory files in some way, since they also contain what you can consider special attributes. That the reason why I think they should be monitored, as a special case.

As monitoring service notifyfs should monitor changes, and not the initial state. But maybe it can be of help here, since the new engine "ignores" some things.

Stef

The new view-engine does not do any monitoring itself: Like in previous versions only KDirLister from kdelibs is used which internally does the monitoring. This of course does not mean that there might not be any open issues in the new view-engine in this regard, but this most probably are only rather small implementation issues and no conceptual issues. Any help is of course always welcome :-)

No, ok when the task of the lookup and the reading of .directory files is not done in some cases, to make it faster, it's possible to let another service (and in this case that's notifyfs) do that, and send the required information asap to new view engine.

Stef

found a funny workaround to get dolphin in kde 4.8 parse the .desktop fle and show my custom folder icons (kubuntu 12.04 beta1)

i copied a blank.gif  (totally blank 2x2 px gif file) into the specific folders .. thats it!

(In reply to comment #21)
> found a funny workaround to get dolphin in kde 4.8 parse the .desktop fle
> and show my custom folder icons (kubuntu 12.04 beta1)
> 
> i copied a blank.gif  (totally blank 2x2 px gif file) into the specific
> folders .. thats it!

Didn't work for me. Neither in the root directory of the mounted share nor in an specific subfolder - both with custom icons.

I can concirm this bug fpr 4.8.2.

Please fix it, this is really nasty!

The reason to disable the reading of .directory files on certain filesystems (network and others) is very understandable. The whole reading of the entire directory is getting too slow. 

To make things work again is making the reading of these files perform better. So please add suggestions and not only drop wishes.

To make the reading better is for example forget about multilanguange support in these files (which make them large and the reading slow) but keep translate the to the user, having translations in a cache/memory. which makes it faster, and the .directory files are not that big anymore.

This is just an idea.

Stef

.directory files generated by adding an icon to the folder, are typically small and do not contain any language specific information.

BTW: Your statement "please add suggestions and not only drop wishes" is not meant to encourage users to report bugs. Do make suggestions one has to be a developer and understand the complex KDE framework. This statement leaves the impression as if only "gurus" are allowed to show up deficits.

Yes you're right. Everyone should react on issues they consider importants. For a moment I had the impression you're dropping wishes while you not realize how much effort and time it takes to tackle the smaller and bigger issues.

Stef

Resetting assignee to default as per bug #305719

(In reply to comment #24)
> The reason to disable the reading of .directory files on certain filesystems
> (network and others) is very understandable. The whole reading of the entire
> directory is getting too slow. 
> 
> To make things work again is making the reading of these files perform
> better. So please add suggestions and not only drop wishes.
> 
> To make the reading better is for example forget about multilanguange
> support in these files (which make them large and the reading slow) but keep
> translate the to the user, having translations in a cache/memory. which
> makes it faster, and the .directory files are not that big anymore.
> 
> This is just an idea.
> 
> Stef

Stef, I can't provide you a suggestion to fix this bug now, but I can provide a suggestion to make this situation stop annoying those who aren't impacted by the slowness problem. Would be too time consuming making this "faster reader mode" switchable through the Dolphin Settings?

This way we could have the choice while the definitive solution isn't released.

2012/9/1 Heitor <heitorm_silva@yahoo.com.br>:
> https://bugs.kde.org/show_bug.cgi?id=288824
>
> Heitor <heitorm_silva@yahoo.com.br> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |heitorm_silva@yahoo.com.br
>
> --- Comment #28 from Heitor <heitorm_silva@yahoo.com.br> ---
> (In reply to comment #24)
>> The reason to disable the reading of .directory files on certain filesystems
>> (network and others) is very understandable. The whole reading of the entire
>> directory is getting too slow.
>>
>> To make things work again is making the reading of these files perform
>> better. So please add suggestions and not only drop wishes.
>>
>> To make the reading better is for example forget about multilanguange
>> support in these files (which make them large and the reading slow) but keep
>> translate the to the user, having translations in a cache/memory. which
>> makes it faster, and the .directory files are not that big anymore.
>>
>> This is just an idea.
>>
>> Stef
>
> Stef, I can't provide you a suggestion to fix this bug now, but I can provide a
> suggestion to make this situation stop annoying those who aren't impacted by
> the slowness problem. Would be too time consuming making this "faster reader
> mode" switchable through the Dolphin Settings?

Yes, that's a good idea.

Earlier I've suggested the same somewhere else on the internet.
I think it's good to add a switch to disable the "fast reading".

Stef

(In reply to comment #28)
> (In reply to comment #24)
> > The reason to disable the reading of .directory files on certain filesystems
> > (network and others) is very understandable. The whole reading of the entire
> > directory is getting too slow. 
> > 
> > To make things work again is making the reading of these files perform
> > better. So please add suggestions and not only drop wishes.
> > 
> > To make the reading better is for example forget about multilanguange
> > support in these files (which make them large and the reading slow) but keep
> > translate the to the user, having translations in a cache/memory. which
> > makes it faster, and the .directory files are not that big anymore.
> > 
> > This is just an idea.
> > 
> > Stef
> 
> Stef, I can't provide you a suggestion to fix this bug now, but I can
> provide a suggestion to make this situation stop annoying those who aren't
> impacted by the slowness problem. Would be too time consuming making this
> "faster reader mode" switchable through the Dolphin Settings?
> 
> This way we could have the choice while the definitive solution isn't
> released.

I would suggest to have checkboxes for slow filesystems, where the user can check NFS, SMB, and so on...

I don't think that's the problem come from the FS's types (SMB or NFS) but more related with the bandwidth of the connexion. 
I use NFS with a 1Gb link with no problem !

Hi,

adding options in the configuration is possible.
But think from the perspective of a moderate user. Will he/she understand
that? He/she has to check boxes in the configuration (the advanced
part of it) about filesystems like smb, nfs, ftp, fuse. That won't
work I guess.

I think it's better to design a module which "heuristic" tries to
determine the lookup/read times of .directory files. If these times
are too big (eg the reading takes too long, slowing down dolphin)
these files/functionality is ignored.

Use sane defaults for the max lookup/read times.

This way dolphin does not have to check the type of filesystem, but
checks the lookup/read time, which was the cause in the first place.
And the user does not have to know about individual filesystems, and
dolphin can just act as it used to when dealing with a fast
filesystem.


Stef


>>
>> This way we could have the choice while the definitive solution isn't
>> released.
>
> I would suggest to have checkboxes for slow filesystems, where the user can
> check NFS, SMB, and so on...
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

(A totally newbie's question.)
Isn't there a way to get the filesystem from the NFS itself? And then, if it is NTFS, consider it «local filesystem», if it's FTP, consider it «remote», etc...

Please forget about the individual filesystems.

The performance of the filesystem is what counts, like Maxime already mentioned.

I think the best option is to make Dolphin heuristicly determine the
lookup/read times. This is not so easy to program, but I think it's
doable.
It makes dolphin very flexible and "intelligent".

Stef

2012/9/7 greatperson <greatperson@ya.ru>:
> https://bugs.kde.org/show_bug.cgi?id=288824
>
> --- Comment #33 from greatperson <greatperson@ya.ru> ---
> (A totally newbie's question.)
> Isn't there a way to get the filesystem from the NFS itself? And then, if it is
> NTFS, consider it «local filesystem», if it's FTP, consider it «remote», etc...
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

(In reply to comment #34)
> Please forget about the individual filesystems.
> 
> The performance of the filesystem is what counts, like Maxime already
> mentioned.
> 
> I think the best option is to make Dolphin heuristicly determine the
> lookup/read times. This is not so easy to program, but I think it's
> doable.
> It makes dolphin very flexible and "intelligent".
> 
> Stef
> 

Look what I suggested was just a workaround and I wrote "This way we could have the choice while the definitive solution isn't released.". The others just improved this workaround with the file systems options.

Your idea of a heuristic algorithm is good but not complete. In this approach we continue going back to the point of not giving the choice to the user. What if the user doesn't mind waiting one, two or more seconds while the directory is loaded once he has its customised icons shown?

In my point of view, a better approach (probably not the best) is load the directory in steps:
1- Read whatever is there to be read;
2- Show the read items (directories, files, devices, sockets, etc.) as "raw items" with a default icon for example;
3- Just do a deeper reading on the items of the first 2, 3 or 4 pages, now discovering what type of file is each one, show the proper icon (customised ones if is the case), thumbnails, etc.

I've just checked and Dolphin seems to has the infrastructure to do it. Actually it already does, try to access a large directory like /usr/bin or /usr/lib and it seems to make a cache too (however, I'm not sure if this cache is really a Dolphin's feature or if it's just thanks to the file system). You can also try out a directory configured to show thumbnails, with some inner directories with pictures, then you will see how they are sequentially displayed.

2012/9/7 Heitor <heitorm_silva@yahoo.com.br>:
> https://bugs.kde.org/show_bug.cgi?id=288824
>
> --- Comment #35 from Heitor <heitorm_silva@yahoo.com.br> ---
>
> Look what I suggested was just a workaround and I wrote "This way we could have
> the choice while the definitive solution isn't released.". The others just
> improved this workaround with the file systems options.

Ok I get it know. I was confused about the double negation in:

"but I can provide a
suggestion to make this situation stop annoying those who aren't impacted by
the slowness problem."

You mean "stop annoying thos who are impacted by the slowness problem"??



> is loaded once he has its customised icons shown?
>
> In my point of view, a better approach (probably not the best) is load the
> directory in steps:
> 1- Read whatever is there to be read;
> 2- Show the read items (directories, files, devices, sockets, etc.) as "raw
> items" with a default icon for example;
> 3- Just do a deeper reading on the items of the first 2, 3 or 4 pages, now
> discovering what type of file is each one, show the proper icon (customised
> ones if is the case), thumbnails, etc.

Yes  of course. The steps here I think are very good. Only load what's
required in the view. This is also done in various other techniques. I
can remeber working in dbase applications (Clipper) were the data is
read from the database. There are only "pages" read from the database,
not the whole db.

I only would not let go my suggestion. I  would add the "heuristic"
method to step3 . If it takes too long, let go of "deeper/detailed"
reading.

There are filesystems (especially where the peer is remote, like
somehwere on the Internet), where is takes way too much time. I'm
working a lot with FUSE fs's, and that can happen.

Stef

Hi,

how things are going?

And where can I follow/contribute the development of this issue??

I write in C, not C++, and earlier attempts to read C++ code failed.
So  I cannot contribute right now.

I would like to write C++, since I'm also working on a fs change
notifier (notifyfs) written in C, which is aimed to be successor of
gamin.

One of the things is does better is to provide fine grained events,
like the change in Extended Attributes. Inotify for example reports a
change in the attributes, but does not mention that a Extended
Attribute has changed, and which.

Futher it'a aimed to cooperate with filesystems like  FUSE and cifs by
notifying them a watch has been set.
See:

http://code.google.com/p/notifyfs/


To test it I have to write a patch to KDE and/or Qt to use notifyfs as
backend, which means of course knowledge of C++.
(too bad, I'm a fan of C, not C++).

Stef

(In reply to comment #37)

> how things are going?

Thanks for your interest in this issue! I'm afraid that things will only progress if someone volunteers to work on this.

> And where can I follow/contribute the development of this issue??

This issue is discussed here, and in the related report bug 178678. Any patches that help to resolve this (which are of course very welcome) should be submitted to http://reviewboard.kde.org/ . See in particular bug 178678 comment 50 for ideas how this could be resolved.

> 
> I write in C, not C++, and earlier attempts to read C++ code failed.
> So  I cannot contribute right now.
> 
> I would like to write C++, since I'm also working on a fs change
> notifier (notifyfs) written in C, which is aimed to be successor of
> gamin.
> 
> One of the things is does better is to provide fine grained events,
> like the change in Extended Attributes. Inotify for example reports a
> change in the attributes, but does not mention that a Extended
> Attribute has changed, and which.
> 
> Futher it'a aimed to cooperate with filesystems like  FUSE and cifs by
> notifying them a watch has been set.
> See:
> 
> http://code.google.com/p/notifyfs/
> 
> 
> To test it I have to write a patch to KDE and/or Qt to use notifyfs as
> backend, which means of course knowledge of C++.
> (too bad, I'm a fan of C, not C++).
> 
> Stef

Yes I've read that. I will try to get things working in kdelibs or
apart from that. The best would be that this "delayed mimetype and/or
.directory loading" is an option in kdelibs, but I will see.

Again, I'm a C programmer, not a C++ one. If anyone has a a **good**
starting point for C++ in general and KDE libs programming please do.

Stef

2012/9/12 Frank Reininghaus <frank78ac@googlemail.com>:
> https://bugs.kde.org/show_bug.cgi?id=288824
>
> --- Comment #38 from Frank Reininghaus <frank78ac@googlemail.com> ---
> (In reply to comment #37)
>
>> how things are going?
>
> Thanks for your interest in this issue! I'm afraid that things will only
> progress if someone volunteers to work on this.
>
>> And where can I follow/contribute the development of this issue??
>
> This issue is discussed here, and in the related report bug 178678. Any patches
> that help to resolve this (which are of course very welcome) should be
> submitted to http://reviewboard.kde.org/ . See in particular bug 178678 comment
> 50 for ideas how this could be resolved.
>
>>
>> I write in C, not C++, and earlier attempts to read C++ code failed.
>> So  I cannot contribute right now.
>>
>> I would like to write C++, since I'm also working on a fs change
>> notifier (notifyfs) written in C, which is aimed to be successor of
>> gamin.
>>
>> One of the things is does better is to provide fine grained events,
>> like the change in Extended Attributes. Inotify for example reports a
>> change in the attributes, but does not mention that a Extended
>> Attribute has changed, and which.
>>
>> Futher it'a aimed to cooperate with filesystems like  FUSE and cifs by
>> notifying them a watch has been set.
>> See:
>>
>> http://code.google.com/p/notifyfs/
>>
>>
>> To test it I have to write a patch to KDE and/or Qt to use notifyfs as
>> backend, which means of course knowledge of C++.
>> (too bad, I'm a fan of C, not C++).
>>
>> Stef
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

I good starting point to learn C++ the "KDE style" is to start with simple Qt tutorials and examples. Start here: http://qt-project.org/doc/qt-4.8/gettingstartedqt.html
Has lots of "Learn More" links, too :)

(In reply to comment #39)
> Yes I've read that. I will try to get things working in kdelibs or
> apart from that. The best would be that this "delayed mimetype and/or
> .directory loading" is an option in kdelibs, but I will see.

If you have any questions about the relevant code or a rough idea how it could be fixed, don't hesitate to send a mail to the kfm-devel mailing list! In particular, please get in touch with us before you start to make large changes in the code to prevent that you spend much time moving in the wrong direction.

Argl! Argl!

Why the hell you are not simply re-enabling this feature?

I'm really pissed of the icons not displaying! But instead of searching for a solution to fix this bug quick you are going for some sophisticated solution which takes month to be implemented an will for sure never be back-ported.

This is what I call user-oriented! *NOT*

Ough why are you making a big issue of it, it looks like you're angry.

Stef

comment #42: Please read http://www.kde.org/code-of-conduct/

Hi,

I've been looking into the code of dolphin and kdirlister.cpp and
kdirlister.h. and must say it's not easy. C++ code allows creating
code to be a haystack, and it is.

Opening an url in kdirlister.cpp (kdelibs/kio/kio/kdirlister.cpp, line
216, kde 4.9.1) is using an kio to do the job.

Now here comes suddenly a "d" where the job is connected to.

This d, what is it?? Declaration is at kdirlister.h, line 653. No
comment, no name which explains, and where can I find the methods

lister->d->jobStarted(job);
lister->d->connectJob(job);

Please explain here?

Futher I haven't found the code to do something with the direntries
(or "items") received, but I have not digged deep yet.

My first impression is that dolphin not is taking into account the
dimensions of the view (the first direntry and the last).
Some basics: when getting direntries from the OS (here via a kio, but
this counts in general) these are totally not ordered. The first step
here would be the ordering of **all** the direntries in the desired
sortorder.
The next step would be taking into account the first direntry into the
view and the last, and try to find additional info about them.

I haven't mentioned the cache here. The kdelibs uses a cache indeed,
and unless a hard refresh is done, entries are taken from the cache. I
haven't found something like a timeout which is very usual in
filesystems to detect "expiration" of entries and a refresh is
required.
I noticed this in Dolphin and Amarok also, which take everything from
a cache. Dolphin has a way for the user to refresh, but Amarok
doesn't..

Stef

Thanks for looking into this! A bug report is probably not the best place to discuss basic questions about programming with Qt, but to understand the purpose of 'd', look at

http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#Using_a_d-Pointer

The header file for the private class of 'KClass' is usually called kclass_p.h, and the implementation of its methods is usually in kclass.cpp.

Ok, it would really be great if we could get back on the topic! This bug is annoying for people who are using NFS based home directories.

NFS has been around for DECADES and people use it successfully to provide home directories from a central storage. We have 15 year old Linux machines here that do this with KDE 1/2! So, now in the year 2012 (!!), KDE 4.7.4 comes along and decides that NFS is per se a "slow" filesystem, no matter what bandwidth or latency the network has... yeah right... people have gigabit ethernet in their homes by now everywhere!

Anyways: I simply removed the corresponding lines in kfileitem.cpp:

diff -Pdpru a/kio/kio/kfileitem.cpp b/kio/kio/kfileitem.cpp
--- a/kio/kio/kfileitem.cpp	2012-06-06 22:49:52.653043147 +0200
+++ b/kio/kio/kfileitem.cpp	2012-09-07 16:21:14.511736277 +0200
@@ -702,8 +702,7 @@ 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;
+            m_slow = Fast;
         } else {
             m_slow = Slow;
         }


This patch completely removes the idea of a "slow" filesystem and reverts to the KDE 4.7.3 behavior!

If you are using openSUSE, I have build the corresponding packages including this patch for
openSUSE11.4 + KDE 4.8: http://download.opensuse.org/repositories/home:/lnt-sysadmin:/branches:/KDE:/Release:/48/openSUSE_11.4
openSUSE12.2 + KDE 4.8: http://download.opensuse.org/repositories/home:/lnt-sysadmin:/branches:/openSUSE:/12.2:/Update/standard/
openSUSE12.2 + KDE 4.9: http://download.opensuse.org/repositories/home:/lnt-sysadmin:/branches:/KDE:/Release:/49/openSUSE_12.2/

Also, an openSUSE bugreport is available here: https://bugzilla.novell.com/show_bug.cgi?id=776141
and I hope Novell comes to the same conclusion that categorizing NFS per se as "slow" is stupid.

I would suggest the KDE developers revert to KDE 4.7.3 behavior to stop the annoyance for all NFS users and think about some good and reliable algorithmic way to test the network filesystem (NFS, Samba) for speed and latency, before they reintegrate the notion of a "slow" filesystem.

Can't say I disagree with J Brauchle's comments.  I'm sure the dolphin devs were attempting to solve a valid problem with this change, but the implemented solution broke a perfectly working setup for people who are on fast networks (which I would think is probably the majority these days).

Implementing an algorithmic approach to determine "slowness" and do the appropriate thing sounds like a great idea, but in the meantime can we acknowledge and revert the actual bug here?  After that, the algorithmic approach can be implemented to improve the situation for users who are affected by slow filesystem access as opposed to what was actually done - break this feature for people where it already worked fine, then spend a year+ trying to figure out some way to make it work again.  Ie., fix the problem for the people who are actually affected, rather than (unintentionally) creating a problem for everyone else and then trying to work backwards to a solution.

J - good suggestion.  I had no idea a fix would be so simple.  I'll try this out on my Gentoo system as soon as I get the chance.

Hi,

I read you have a big problem with the not showing extra info on
certain filesystems. I do too. I also develop FUSE filesystems, and
they provide .directory files whenever asked for, for showing a custom
icon only.

I put effort in making this to work better, but it will take a long
time I'm sure. I will even do suggestions to do major patches to
replace the whole kio thing by a FUSE based sollution to access
various resource (why: FUSE offers filesystem access with all the
features, kio's don't, kios try to reinvent the wheel what VFS in
combination with FUSE already provides) in combination with a
replacement for gamin, fs notifier. You have been warned. See for a
GVFS like sollution for every environment:

https://github.com/stefbon/fuse-workspace

and an overlay filesystem which handles fs notify requests:

http://code.google.com/p/notifyfs/

You NFS folks, this service is trying to make fs notify work with
network filesystems like CIFS and NFS (kernel filesystems). How to do
this is still an issue. In my opinion filesystem handling and things
like fs notify requests/events should not be the task of the graphical
environment like KDE.

Any way, I do not have any working yet, not a clue. So in the meantime
it's a good idea to solve this with a sollution you propose if you ask
me.

Stef

I toataly agree with J Brauchle. Thanks for the patch, I will foward it to the Magei community.

Sweet.  I just applied J's patch and now I have my pretty icons back in KDE 4.9.1.  :-)

Thanks again!

Hi,

I'm still trying to understand steps from
dolphin->kdelibs->kio->results->back to Dolphin.

Ive found the code in kdirlister.cpp, line kdelibs/kio/kio, line 1156
the slotEntries function.

At line 1187 same file is determined the to determine the
"delayedMimeTypes" from all currently dirlisters connected.

I do not know what that does, but it looks like it does matter.

First is there a place - developers maillist - where I can share this??
I do not think this is the best location for me to share what I've
found and for questions. Is there one?

Second I think it's worth to try to use another cache than now used in
kdelibs. I've developed an overlay fs notifyfs which is:

a. it's an overlay fs, so it's a cache of the "real" underlying filesystems.
Applications can get a list of cached entries, where a timeout is of
course used. And apps can get a up2date list of entries.

b.it's a filesystem change notifier, and tries to detect differences
with the underlying fs, and if there is one, forward the event to
interested clients, and sync with the underlying fs so notify fs is
up2date again.

c. it's a database, apps can do all kinds of queries, using indices
(sort orders) and begin and end position (=view), using filters,
through a socket. It can if desired provide additional info like
mimetypes, direct or delayed.

One thing notifyfs does not work with is kio slaves.. but there are
sollutions for that.

Where can I do this suggestions?

Stef

The kde-core-devel list is the best place to discuss kdelibs development, I think. However, I think the suggestion to add another fs layer which does not work with kioslaves is rather unlikely to be accepted. There must be an easier solution for this.

2012/9/29 Frank Reininghaus <frank78ac@googlemail.com>:
> https://bugs.kde.org/show_bug.cgi?id=288824
>
> --- Comment #53 from Frank Reininghaus <frank78ac@googlemail.com> ---
> The kde-core-devel list is the best place to discuss kdelibs development, I
> think. However, I think the suggestion to add another fs layer which does not
> work with kioslaves is rather unlikely to be accepted. There must be an easier
> solution for this.
>
I do not suggest only for this sollution. When I'm looking how things
are done in kdelibs, creating a cache, and how complicated it's done,
I suggest the whole current implementation to be replaced by a using
an overlay fs (a FUSE based fs) which acts as filesystem change
notifier AND a database apps can query AND a cache, which by it's
design close to the real underlying fs. I know that that will not be
accepted just like that. I have to come with good arguments.

See:

http://code.google.com/p/notifyfs/

Right now it's only a filesystem change notifier clients can connect
to, but it's easy to make it a service clients can get directory
information from, by just sending a request via a socket:

int send_request_direntries(char *path, unsigned long long uniqueid,
int (* filter)(struct item_struct *item), unsigned char reload, int
sortorder, char *name, int maxentries)

where:
path: path of directory to list
uniqueid: id to use for futher communication. This is usable when
doing communication with an answer/reply mechanism
filter: the filter to skip items
reload: force a reload or not
sortorder: use a specific index (different indices are kept by notifyfs)
name: name of first entry, if empty than start from top
maxentries: maximum of number of entries, has to do with the max
number of entries possible in a view

On the socket the client will receive items, along with the uniqueid.
If reload==1 it's garanteed it's up2date.

(I might forget here something, but this is globally the idea)

Futher, clients can also  send a fs change notify watch. Notify fs can
send events back to the client when something occurs.

And it's a database, like every filesystem is in a way a special database.
So additional data can be attached to an ino, like mimetype, and
special indices are maintained by notifyfs.

When browsing/scrolling additional calls are possible to readahead.

This is all very easy to program.

For a replacement for kio's I have another sollution:

https://github.com/stefbon/fuse-workspace

It offers access to various resources like smb shares, usb drives and
cdroms using a virtual browseable map's and different "workspaces" as
I call them, like:

~/Devices/... cdroms usb sticks etc ...
~/Network/... windows network FTP webdav etc ...

See:

https://github.com/stefbon/fuse-workspace

It's possible (it's the choice of the administrator) to access shares
using libsmbclient or using cifs (by mounting them). Other sollutions
like Gnome VFS or the kio slaves use libsmbclient.

It works in every environment, and does not require a graphical
environment. For example it works also in the textconsole.
Cause it works on filesystem level. This makes cooperation with a
cache like notifyfs very easy.

But I will suggest it in the kdelibs devellist.

Stef

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

@Stef Bon, any news about the resolution of this bug?

2012/11/22 Heitor <heitorm_silva@yahoo.com.br>:
> https://bugs.kde.org/show_bug.cgi?id=288824
>
> --- Comment #56 from Heitor <heitorm_silva@yahoo.com.br> ---
> @Stef Bon, any news about the resolution of this bug?

Hi,

first I've contacted David Faure for some reason, and we came to discuss
the bug, and me working on it. He said also somebody else (Martin
Koller) is already working in it. So there has been some
miscommunication.

What and where I do not know, but I stopped my efforts, and I was not
that unhappy. C++ is for me very difficult to read.

But the good (!?) news is that I'm working on notifyfs, which aims to be:

a. an overlay fs
b. a cache
c. a fs change notifier which uses the fs notify methods the host/os offers
d. a database gui clients can query for attributes and properties like mimetypes

I've written a simple client which can get directory entries in a
directory, where startpoint (name) and the maximum number entries are
set. As you know gui clients are not interested in the complete
contents of a directory, but only a subset, depending the gui window
can offer.

Synchronisation goes via a socket, but that is not very efficient.
I've understood that shared memory is the best method for this, it's
maintained by notifyfs, which has read/write permissions to it, and
clients have only read rights.

A socket is still required to send messages that certain data is
synced/up to date.

Right now I'm working on it and do not expect a result before next weekend.

At this moment only :
- inodes
- entrys and names
- directory struct

I'm working on to make available to clients.

The way clients should work is:

at start the client should also use the shared memory. How to do this
I'm working on still.

clients send a message via socket to notifyfs they want a certain
subset of a directory is up to date:

- path of directory
- name of first entry
- above name is directory or not
- maximum of number of entries
- set a watch also?
- mask of watch if required

Notifyfs does the required action to make the requested set of entries
up to date, and sets the watch (using the os specific method), and
replys with a "up to date" message. After that the client can read the
entries.

At this moment mimetypes and icons are not yet supported.
Futher I've an api for fs events, aimed to be os independend.

See the not so up to date source:

 https://github.com/stefbon/notifyfs

Stef

So on openSUSE 12.3 Beta1 using a beta of KDE4.10 (4.9.97), this but STILL exists.

A workaround has been posted in this thread months ago... still, nobody seems to care to FIX this stupid hole until a real solution has been found. Instead, users are left frustrated and with a desktop icons because developers seem to take ages to create a completely new solution from the ground up!

Could anyone please integrate the workaround into KDE4.10 until the bigger solution is ready?

bug 178678 will be  fixed in KDE SC 4.10.2, so this one probably too.

Thanks Jekyll for the hint, let's close it then.

Have any of you tested this release to confirm if such issue was fixed?

It looks like the problem is gone... But I'm just testing for a few seconds.

It would be nice if someone else could confirm!

I can confirm. Works on a local partition mounted with ntfs-3g.

Works for me, too.
Kubuntu 12.10, KDE 4.10.2.

Hi,

I cannot confirm for cifs. It does not do anything with a .directory
file in the users
home directory on the SMB server, after it's mounted.

Stef

Fix for Ubuntu 12.04 based on J Brauchle's patch, attached here:

https://bugs.kde.org/show_bug.cgi?id=290666

For years after this bug was reported, I can confirm that dolphin is still not able to handle custom icon in 4.13.3..... 
I don't understand the point of reporting bugs if nobody cares anyway, and if they are only willing to bring new functions in code, not to solve bugs...

Handling custom icon, is something windows 3.11 was doing without problem...

(In reply to maxime.haselbauer from comment #67)

Thanks for taking the time to comment on this bug report.

> For years after this bug was reported, I can confirm that dolphin is still
> not able to handle custom icon in 4.13.3.....

The issue that was reported first in this report was fixed just a few days later (see comment 5), and that bug was never in a stable Dolphin version, only in a beta release.

The later comments are about another problem, namely, that custom icons did not work at all in KDE for directories on NFS shares. This issue has been fixed more than two years ago (see  comment 59).

> I don't understand the point of reporting bugs if nobody cares anyway, and
> if they are only willing to bring new functions in code, not to solve bugs...

Please read all comments in a bug report before making such statements. The problem that you see on your system is definitely different from everything that has been discussed here, and it seems that you are the first one who reports it.

Please file a new bug report about your problem, and include additional information, such as:

* Is the issue only reproducible in Dolphin, or are custom icons also missing in the file dialog of, e.g., KWrite and FolderView?

* Can you reproduce this in every directory, or only on external devices or network shares?

* Is this problem reproducible with a new user?

Thanks!

(In reply to maxime.haselbauer from comment #67)
> For years after this bug was reported, I can confirm that dolphin is still
> not able to handle custom icon in 4.13.3..... 

I've just started seeing something like this in Dolphin 4.14.1 on Kubuntu 14.10 64b but I don't know if it is related. It may be by design. :)

This happens with folders on local or on NFS shares.

If I view a folder in 'Icons' mode and it has subfolders with custom icons, those icons will only show correctly if I turn 'Preview' off. 

With 'Preview' on, I see a white sheet icon with 'filmstrips' of some of the images from within that folder.

This only occurs where the subfolder contains at least one image.

If the subfolder contains no images, then the subfolder icon is unaffected by the state of the 'Preview' button.