BTW, have you checked if the thumbnails are still generated for non-removable but encrypted filesystems? My whole system is encrypted (except for /boot), so it would be a performance loss if no thumbnails were ever cached.

for (Device device: list) {
    StorageAccess *storageAccess = device.as<StorageAccess>();
    if (canonPath.startsWith(storageAccess->filePath()) && storageAccess->filePath().size() > match_length) {
        match_length = storageAccess->filePath().size();
        match = device;
    }

Use Solid and ask it if the device is on an encrypted device. If Solid does not have such an API, add it.

In D27804#621988, @sitter wrote:

In D27804#621970, @thiago wrote:

Still want to see that round-trip.

But why? Converting an smbcUrl to a QUrl would literally be useless code.

Still want to see that round-trip.

looks good to me.

STD3 also forbids domain labels ending in dash, so can you add a test for smb://[fe80::]/ too? You'll need to adjust your code

Looks good, but testing should be extended. I suggest:

Yes, it's been supported for years.

Good catch.

This really needs to be fixed in Qt. 5.13.1 has an overhaul of the system, please make sure that the patch is still required there and does not make things worse.

QFile::copy already implements FICLONE, sendfile() and Darwin's clonefile().

Not endian-dependent, like the memcpy solution. Make sure the other side is adapted to match.

+1

Is anyone working on the ability to open a new profile? I ask this because I had a shortcut assigned to open a root shell (Ctrl+Alt+R) and was quite surprised to find out that it didn't work anynore with no way to get it back. This is not the same as opening a new tab and switching profiles, since that won't change the command that was started.

As for truncating UTF-8 multibyte sequences in the middle, when you convert back using QFile::decodeName, it'll be nonsensical. But I don't think it really matters since you're truncating and using the display string anyway, so you're already losing data. This wasn't a recoverable conversion anyway.

I cringe a little when you apply QFile to a URL, but this is probably safe enough.

This new backtrace *is* a stuck application. Please report the issue to Mesa (dri/i965). Cc me, I can walk three paces in the office to the Mesa devs and help them figure out what's happening.

I repeat: there's no indication in the backtrace that it is stuck. What's your evidence that it is? You wrote an application that shows nothing and never exits. Now it showed nothing and didn't exit. That's not stuck, that's the expected behaviour.

This last backtrace does not show anything stuck. Thread 1 was actively running, in fact (it's inside of malloc).

The patch is innocuous. I don't see *how* it can solve anything, though, because I don;'t know what DrKonqu::cleanup does.

It looks good to me.

Much better, thanks.

qhelpgenerator is coming back in 5.12.1. You may simply tell people to skip the .0 release and upgrade.

In D14302#297515, @dfaure wrote:

The idea of the old code was: if I can't get the lock, then someone else is already in the process of starting kdeinit, so I'll just wait for that to happen, by locking again, i.e. blocking on purpose, and then checking that the DBus name is up, i.e. the other process did manage to do it successfully.

In D14302#297159, @jtamate wrote:

(gdb) disass
Dump of assembler code for function _ZN9QLockFile7tryLockEi:
   0x00007f54be8bc752 <+2>:     mov    $0xffffffff,%eax
...
   0x00007f54be8bc76d <+29>:    test   %esi,%esi
...
   0x00007f54be8bc772 <+34>:    cmovs  %eax,%esi
...
   0x00007f54be8bc78c <+60>:    movslq %esi,%rsi
   0x00007f54be8bc78f <+63>:    callq  0x7f54be962150 <QDeadlineTimer::QDeadlineTimer(long long, Qt::TimerType)>

Quickly checking on openSUSE Tumbleweed

This is indeed Forever. How did it get there?

Can you print the contents of the timer object inside tryLock()?

In D14302#296671, @jtamate wrote:

Another hypothesis:

QDeadlineTimer::QDeadlineTimer(qint64 msecs, Qt::TimerType type) Q_DECL_NOTHROW
    : t2(0)
{
    setRemainingTime(msecs, type);
}

As t1 is not initialized and QDeadlineTimer::setPreciseRemainingTime only add to t1, it could be any value instead of 0?.

Should I open a Qt bug?

Quick testing via gdb:

In D14302#296479, @dfaure wrote:

I agree about tryLock(0) should return immediately, tryLock(-1) should block forever -- I wrote that code and that docu ;-)

Thiago wrote QDeadLineTimer later on though, and ported QLockFile to it. Thiago, any input?

That doesn't make sense. There's QFile::encodeName in the code.

Looks good.

The patch that I can see accomplishes what the description says it should do. And I agree with the idea of the patch.

Why do you ask for a rewview then not wait for the review?

This class isn't hooked up to anything. It's technically correct as an FD sender and receiver. What I want to see is how you use it, because that's extremely important to get right.

Qt 5.10 will have QFileInfo::birthTime too.

In D5972#112994, @rjvbb wrote:

Yes, here too, haven't had time to read back up on and go through the whole Qt code review process. What branch should I target, anyway?

Makes sense to work around older versions of Qt without the fix.

In D5865#112747, @rjvbb wrote:

In D5865#112743, @thiago wrote:

Fix the source code.

If certain third-party libraries can't compile under MSVC 2015 (or even 2017!) with default compiler options, they don't deserve to be used. Blacklist them.

That may work for Qt but is not an acceptable attitude for ECM, IMHO - and MSVC is problematic enough to build KF5 code for other reasons not to jump through hoops for it. You cannot expect FOSS projects to avoid Boost because it uses less common feature of the standard, big ole bad M$ cannot be bothered to write a proper compiler. I'd be all for blacklisting such compilers, if anything had to be blacklisted.

In D5865#112737, @rjvbb wrote:

In D5865#112697, @thiago wrote:

Why are we spending time in named operators? It's much easier to fix the source code not to use them and then the problem goes away.

This is about adding a convenience macro for projects that have dependencies using named operators, like certain Boost modules.

In D5865#112679, @rjvbb wrote:

That option only exists in MSVC 2017.

Should we have deduce that from the docs I cite in the CMake comments? I'm willing to believe that I misread as far as support for named operators is concerned, but they do mention 2015 Update 3 specifically as the appearance of /permissive-.

In D5865#112549, @rjvbb wrote:

If a compiler is problematic in general it may not be worth it trying to account for it in a macro, trying to coerce it into doing something it cannot handle. I don't think that's a reason not to implement the macro at all though. Even if we cannot figure out from what version onwards the /fpermissive- option works it could still be useful for cross-platform code that really needs named operator support to let the macro print a warning (or raise an error) when it is built with MSVC.

In D2545#69187, @kfunk wrote:

In D2545#69091, @thiago wrote:

There doesn't seem to be a way of doing some clean up before the threads are forcibly killed.

Maybe if I abuse qtmain().

This would only fix it for non-console GUI applications if I understand correctly. That's what we have here, but we'd still keep console applications buggy. There's no way to inject code before ExitProcess() with a plain console application.

More information on this Windows behaviour:

In D2545#69083, @kfunk wrote:

Here's the other problem: it's possible for threads to simply disappear on Windows. Given that I see "dllmain" in the backtrace (though not DllMain), I can't rule out that this has happened. Qt 5.6 has a workaround to another deadlock caused by Windows. Can you try to cherry-pick 3ec57107cedb154f256e3ad001ea5475cc64fa94 from 5.8?

With 3ec57107cedb154f256e3ad001ea5475cc64fa94 applied: Still dead-locking, same backtrace.

In D2545#66904, @thiago wrote:

Commit ad66dbe305cff72443f4d3484191872d56e6dfbb in qtbase did try to solve this by disconnecting the senders when the objects were getting deleted. closeConnection() is called before the thread exits (from QDBusConnectionManager::run), so I don't know how there's still a BlockingQueuedConnection active.

Is it possible that the service began being watched during destruction?

In D2545#66545, @kfunk wrote:

In D2545#65976, @dfaure wrote:

Actually, I think Thiago's still waiting for a backtrace of all threads.

I think I've already said this via other channels: There's only one thread left at this point.