Commit c58fdc63 authored by Harald Sitter's avatar Harald Sitter 🌈
Browse files

smb: no discovery cap on file listing

File and share listing can take a very long time as they are IO bound on
the remote, so if one is listing a large directory on a HDD it may well
take minutes. Equally sending huge listings over the wire may take a
while if not enough throughput is available. So don't cap the execution
of these discoveries at all.

Server discovery retains the timeout, mostly because I don't want to
remove it in 20.08 though an argument could be made that we should trust
in the reliability of the discovery stacks to not get stuck on random
unforseen misbehavior of servers.

BUG: 427644
FIXED-IN: 20.08.3
parent c3efd4a7
......@@ -450,11 +450,18 @@ void SMBSlave::listDir(const QUrl &kurl)
wsd->start();
qCDebug(KIO_SMB_LOG) << "Modern discovery set up.";
// Conceivably discovery could be kept from finishing by breakage in the stack.
// At some point we'll forcefully consider it finished to prevent broken servers and the like from
// holding up use of potentially working servers.
// NB: This must only be done for SMBURLTYPE_ENTIRE_NETWORK. Other types
// may take a long time to discover by necessity - e.g. listing a server with a
// million shares or a directory with a billion files. https://bugs.kde.org/show_bug.cgi?id=427644
QTimer::singleShot(16000, &e, quitLoop); // max execution time!
}
qCDebug(KIO_SMB_LOG) << "Starting discovery.";
smbc->start();
QTimer::singleShot(16000, &e, quitLoop); // max execution time!
e.exec();
qCDebug(KIO_SMB_LOG) << "Discovery finished.";
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment