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

--- Comment #8 from Méven Car <meven....@kdemail.net> ---
(In reply to Harald Sitter from comment #7)
> I've already tried my luck on the worker, but couldn't really find it
> misbehaving. The thing to note is that this is an all-success scenario.
> 
> The first copy completes successfully with everything in working order. The
> second copy does only stats on the dolphin side (noticing it is an overwrite
> and issuing the prompt) and the plasma side does only stats and gets,
> getting stuck.
> 
> Following your suggestion on trying another worker: the same happens to
> sftp. Overwrite a file -> plasma runs mimetype checks -> adding some
> strategic qdebugs I see SFTPInternal::sftpSendMimetype never returns, and
> for that worker we can be certain that it's not error-finished confusion
> because it uses the `Result` return type system.
> 
> What I've noticed is that plasma (or more specifically notifications'
> fileinfo.cpp in plasma-workspace) is running two mimetypefinders at the same
> time on the same url, could that be what's causing the confusion? Although
> I'd expect to at least one of them to return TBH.

So I see three issues, on the kio side we should allow multiple calls but early
return failures when the resource is busy, we fail to notice that the file is
being written to as we get() it, but since samba does not offer a better
solution AFAICS we can't do much better.

And a second possible in plasma-workspace/applets/notifications making
redundant MimeTypeFinderJob, the error seems to be on the QML side where two
NotificationItem (with their JobItem using FileInfo) can get instantiated
somehow in FullRepresentation and NotificationPopup.

A third issue is that MimeTypeFinderJob would like ::stat to fill UDS_MIME_TYPE
but SMBSlave::statToUDSEntry does not (even naively using fileName),
MimeTypeFinderJob has then a fallback using get().
Hence why we have successive calls to stat() and get() which should misbehave
while SMBSlave::put is running.

SMBSlave::open() has a short path to download 1kB of the file for mimetype
determination (as well as SFTPInternal::sftpSendMimetype file.cpp does fill
mimetype in open() this seems like a strong expectation).
It seems to me MimeTypeFinderJob could use similar open() (or read())
short-path fallback instead of a complete get().
That would be the quickest path to a fix and more added general stability
across ioworkers.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to