Bug 304123 - KGlobalSettings::downloadPath() creates dir instead of just return it
Summary: KGlobalSettings::downloadPath() creates dir instead of just return it
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: kdeui (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 316400 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-27 07:23 UTC by Jekyll Wu
Modified: 2024-09-14 17:06 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jekyll Wu 2012-07-27 07:23:07 UTC
I have changed the download path from the default "/home/xyz/Downloads" to "/home/xzy/rekonq". However, rekonq always creates the "/home/xyz/Downloads" folder on start up .

This is not a recent regression. My git fu shows that the problem exists ever since commit d76f6bdb544f6ba4fb6b92fbeb36bfe25450eb1f . 


Reproducible: Always
Comment 1 Andrea Diamantini 2012-07-27 14:26:35 UTC
right :)
Never noticed it. My downloads dir is /home/adjam. Try fixing it in the afternoon...
Comment 2 exzemat 2013-01-18 19:48:47 UTC
Same at home.
archlinux with the last rekonq 2.0
nothing to do since august last year ?
thanks
Comment 3 exzemat 2013-01-18 21:30:49 UTC
in fact, the problem is that rekonq automatically create the default directories witch is specified in kde system setting/"user account and password"/"directory"
I've changed default's directory for the download's folder in Kde sytem settings, and it's OK now.
Comment 4 Brendon Higgins 2013-02-15 13:38:22 UTC
For the longest time I was wondering which program was blindly creating a "Downloads" folder automatically (which I then have to delete). I only just realized (to my surprise) that it was rekonq. Now I'm a bit shocked to see that it does it regardless of the preference I set in the options dialog.

In my opinion, the real bug here is that rekonq creates this folder at the wrong time and for no reason. Why does it do it automatically upon startup, rather than only if necessary when the user downloads something? (At least if it did the latter, only creating "Downloads" when the user asks to download something, then it would have been far more obvious to me which the offending program was.)

FWIW.

Peace,
Brendon
Comment 5 Andrea Diamantini 2013-02-15 15:04:09 UTC
well... what we are actually doing is just call at startup the kdelibs method "KGlobalSettings::downloadPath()", to get informed about KDE Downloads dir.
I don't have a clue why a get function takes care of creating a dir in your system. IMHO, rekonq is innocent for this problem, also being responsible for the "offending" call.
Comment 6 Brendon Higgins 2013-02-15 15:48:49 UTC
Hi Andrea,

You are right, and a cursory look at the code for "KGlobalSettings::downloadPath()" shows that it does actually create this path if it does not exist. You can see this bug is also triggered when you go to System Settings->Account Details and look at the Paths: it generates the "Downloads" folder. Notably, this behaviour is inconsistent with all the other path getter functions in KGlobalSettings. None of them create the folders that the paths refer to, and nor, IMO, should downloadPath().

I suggest forwarding this bug to the appropriate maintainers.

Peace,
Brendon
Comment 7 Jekyll Wu 2013-03-09 09:40:31 UTC
*** Bug 316400 has been marked as a duplicate of this bug. ***
Comment 8 Simon Solinas 2013-06-08 12:34:29 UTC
Rekonq still creates the folder download every time I start it ... KDE SC 4.10.4 on arch and chakra
Comment 9 Rémy Epke 2015-05-01 18:06:42 UTC
Qt: 4.8.6
KDE Development Platform: 4.14.7
rekonq: 2.4.2
3.19.4-1-CHAKRA
Two machines, same problem.
Also testing Plasma 5 on Chakra on a different partition, still has this problem.
Any prospect of a fix?
Comment 10 Christoph Feck 2015-05-01 18:09:03 UTC
You could test the frameworks version of rekonq, but I am not sure how usable it is.
Comment 11 Rémy Epke 2015-05-01 19:24:53 UTC
(In reply to Christoph Feck from comment #10)
> You could test the frameworks version of rekonq, but I am not sure how
> usable it is.

Sorry mate, I have no idea what you mean by "the frameworks version".
I don't generally use rekonq anyway but I did notice this behaviour when giving it a try and figured I'd report.
Comment 12 Christoph Cullmann 2024-09-14 17:06:33 UTC
Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have resolved this bug.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann