move it so it's with the other bits above

depending on the use case, wouldn't it be enough to implement this TODO instead?

missing "else" after this line?

same here -- duplicated code => move to helper function

booleans parameters are bad, please make it an enum.
https://wiki.qt.io/API_Design_Principles#The_Boolean_Parameter_Trap

+ docu missing including @since tag.

Remove the TODO :-)

So, we don't really skip it. We just use a "fast and less precise" mode.

Sounds like this should be called DetermineMimeTypeFromExtension (though that's incorrect for http),
or FastMimeTypeDetermination (but people then think it's a good idea to call this in all cases...)
or SkipMimeTypeFromContent -- maybe better?

It reads like a bit of a hack here, because reading .directory is unrelated to mimetype determination.

But I think your idea is that isDir() is what we don't want to call right?
Another way to do this, then, would be to change isDir() to have an early return false if mimetype determination is skipped?

my suggestion would simplify this here too

Remove this comment, no longer true (only keep the first line, remove the other 3)

What about the other way around? I think this needs the symmetrical test to call item.init() if needed
(and the corresponding unittest, write it first)

This use of d->m_entry needs a call to init(), no?

This kind of method (which only uses d->m_entry in one place) could be simplified by just doing

return entry().stringValue(....);

Then the init() would happen inside entry().

This would work in user() just above, too.

There is one thing I've been wondering back and forth about: the alternative way of doing this, which is to call init() unconditionally and testing the bool first thing in there.
The benefit is that it would reduce the code size overall, and greatly simplify the top of this method (two calls to init, done).
The downside is that for the reader, a call to init() might in fact do nothing (and it reads like it's doing something, until going there to check). So it's maybeInit(), urgh.

Ah, in another code base (QMimeType) I wrote ensureLoaded(). This could be ensureInitialized() ?

Sorry for not suggesting this earlier. Do you agree that it would make the code better?

No no, this won't work. entry() returns a copy, not a reference.

here entry() would work, no?

It's more fragile this way here, because the reader of this code won't see that d->m_bLink is initialized indirectly via entry() calling init().

This is why I had only suggested to use entry() in a few places, not in those other places which need init() for other reasons anyway.

By fragile it means, it works today, but any further work/refactoring of this code is likely to break.

Same problem in linkDest().