Bug 331223

Summary:	Wallpaper slideshow traverses into the original directory of symlinked files
Product:	[Unmaintained] plasma4	Reporter:	sparhawk <kdebugs>
Component:	wallpaper-image	Assignee:	Paolo Capriotti <p.capriotti>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	mtmkls, plasma-bugs
Priority:	NOR
Version:	4.12.1
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description sparhawk 2014-02-17 00:21:12 UTC

I'm trying to work around bug 325380, by creating a directory with a single image in it. This image is a symlink to a picture that will change regularly. I then set the wallpaper to a slideshow pointing to this directory.

At first, only this one image will be shown, as expected. I can right-click the wallpaper, and select "Next Wallpaper Image", and this confirms that there is only one image in the slideshow. However, I find that after a while, the slideshow starts to traverse the actual directory that contains the symlink! It also traverses the subdirectories.

I'm using Variety to automatically download and change this wallpaper file. I'm not sure if the timing of the bug occurs when new wallpapers are downloaded.

Reproducible: Always

Steps to Reproduce:
1. $ mkdir /path/to/one_image
2. $ ln -s /path/to/images/image.jpg /path/to/one_image/image.jpg
3. Select wallpaper to be a slideshow of images in /path/to/one_image
Actual Results:
Originally, slideshow comprises of one image.
After a while, images from subdirectories of /path/to/images are incorporated.

Expected Results:
The slideshow should only ever include /path/to/one_image/image.jpg. It should never even think about visiting the directory of the target of the symlink.

I tried replicating this bug in a simplified sense, by manually copying new files instead of using Variety, but I could not. Still, I cannot imagine that Variety is capable of doing anything wrong to stimulate this bug.

FWIW, with Variety, the symlink I use points to ~/.config/variety/wallpaper-kde.jpg
Also, I'm using the "Grid Desktop."

Comment 1 sparhawk 2014-02-17 00:47:20 UTC

Since I can't replicate it with minimal conditions, I though perhaps KDE was caching previous targets to the symlink. I tested that too, and this was not the case.

Comment 2 sparhawk 2014-02-17 03:01:15 UTC

I've also tried using a hardlink to the file instead, and I get the same bug.

Also, the new photos incorrectly added to the slideshow are newly-downloaded images in the subdirectories. Other photos that were already present in the subdirectories before the setting change are not cycled through.

Comment 3 miklos 2014-02-17 12:42:33 UTC

I can't reproduce this on Debian (kde 4.11.3)

Comment 4 sparhawk 2014-02-17 13:08:22 UTC

miklos, is that using Variety as well? That was the only way I could reproduce it, but, as I mentioned, I still can't imagine how it's Variety's fault.

Comment 5 miklos 2014-02-17 18:28:32 UTC

There is no Variety in Debian AFAICT. It's possible that it adds its target folder to the list of slideshow folders silently, but I took a quick glance at its code, and didn't see anything like that.

Comment 6 sparhawk 2014-02-19 00:48:58 UTC

I don't think it does anything that tricky. In fact, when you first start it, it tells you that you are using KDE, and it cannot modify the KDE wallpaper directly, without KDE libraries. Hence, you need to manually specify the wallpaper for KDE users.

Also, after a restart, the KDE wallpaper slideshow reverts back to the single image as expected.

Comment 7 Nate Graham 2018-06-08 19:01:19 UTC

Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham