https://bugs.kde.org/show_bug.cgi?id=450905
--- Comment #10 from skierpage <skierp...@gmail.com> ---
(In reply to skierpage from comment #9)
> It seems the fix in kdeconnect is to expand ~ before handing the path to
> lower-level software.
If this is the problem, it could be in how share/shareplugin.cpp calls:
QUrl dir =
QUrl::fromLocalFile(config()->getString(QStringLiteral("incoming_path"),
defaultDownloadPath));
I don't think this does anything with "~" in the path, and it's unclear if QUrl
understands a "~" in a file URL, and then KIO::mkpath(dir) fails. (As an aside,
with decent language support for typing, it should be impossible to pass an
unparsed path string with ~, $HOME, %1 or whatever into a function that takes
an O.S. path -- rewrite it in Rust ;-) .)
> I've used KDE Connect so long I can't remember what its default Save path was.
I think it uses QStandardPaths::DownloadLocation which defaults to
"~/Downloads".
If I run `/usr/libexec/kdeconnectd --replace` in a terminal (I can never
remember how to view qWarning() output), sending a file from Android prints:
2024-05-26T17:19:51 default: couldn't create QUrl("file:~/Downloads")
2024-05-26T17:19:51 default: couldn't create QUrl("file:~/Downloads")
2024-05-26T17:19:52 default: QNetworkReplyImplPrivate::error: Internal
problem, this method must only be called once.
2024-05-26T17:19:52 default: QIODevice::write (QFile,
"~/Downloads/MYIMAGEFILE.jpg"): device not open
...
Hope this helps.
--
You are receiving this mail because:
You are watching all bug changes.
