| Summary: | KGlobalSettings::downloadPath() creates dir instead of just return it | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Jekyll Wu <adaptee> |
| Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | brendon, bugs, cfeck, cruzki123, danielstewart, exzemat, ksolsim, testflacon |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jekyll Wu
2012-07-27 07:23:07 UTC
right :) Never noticed it. My downloads dir is /home/adjam. Try fixing it in the afternoon... Same at home. archlinux with the last rekonq 2.0 nothing to do since august last year ? thanks 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. 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 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. 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 *** Bug 316400 has been marked as a duplicate of this bug. *** Rekonq still creates the folder download every time I start it ... KDE SC 4.10.4 on arch and chakra 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? You could test the frameworks version of rekonq, but I am not sure how usable it is. (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. 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 |