Given there was no principal objection and this code is following the pattern of D10724, going to push now as well, so it gets some more field-testing before next weeks tagging.
Given this code is the same as D10724, going to push now as well, so it gets some more field-testing before next weeks tagging.
I seem to be making a mess of this commit. Sorry for that.
https://p.sc2.nl/B13Etcldf with the changes.
@svuorela: Thank you very much. I will try you suggestion as soon as I'm able to get the tests compiled.
This commit leads to
I don't like the idea of a flag for this in the API. It just moves the problem (of whether it's safe / a good idea to clean up) to the applications, who are not in a better place to decide about this. Better make it happen all the time, and better make it work right. A flag almost sounds like a excuse for a half-hearted feature ("if it works badly in case XYZ, then apps can just opt out"). I don't see why the app would care, really. It wants to copy A to B, and wants to know if it worked or not; details like cleaning up on cancel are best handled by the KIO library.
"unlink() in most of the modern filesystems is not affected by the size of the file" doesn't match my experience, I have seen konqueror/dolphin freeze for 10s while deleting a 8GB file (on a somewhat old system, no SSD). And that would actually be the reason for this patch to go in. But on the other hand, I have a hard time believing that this patch doesn't make things slower for the case of many small files, due to the communication overhead with the kioslave (and that's the reason I wrote this code in the first place).
A quick review of some quirks and weirdnesses in c++
Please try that. For unknown types baloo-widgets (responsible for infopanel/tooltips) falls back to value.toString(), no idea what will happen when you feed it with binary data. The cover properties return binary data, right?
I don't know dolphin works, but given how KFileMetadata is designed, the new tags should be ignored until explicit support is added in dolphin.
Nice! How do the infopanel or tooltips of dolphin look with this?
That's great. Any clues to solve this?
[ 35%] Building CXX object src/file/extractor/autotests/CMakeFiles/extractorIOTest.dir/__/iohandler.cpp.o [ 35%] Linking CXX executable ../../../../bin/extractorIOTest CMakeFiles/extractorIOTest.dir/__/iohandler.cpp.o: In function `Baloo::IOHandler::nextId()': /home/super/devel/kde/src/frameworks/baloo-flex/src/file/extractor/iohandler.cpp:46: undefined reference to `Baloo::DocumentId::DocumentId(unsigned long long)' /home/super/devel/kde/src/frameworks/baloo-flex/src/file/extractor/iohandler.cpp:49: undefined reference to `Baloo::DocumentId::operator unsigned long long() const' collect2: error: ld returned 1 exit status
- idutils: Use DocumentId constructor
- DocumentId: Add 'QDebug operator<<'
@alexeymin: Could you use inline comments, please. That would help me a lot. And: thank you for your comments. It is really nice to have someone commenting without me poking first. ;-)
To solve this warning you need to fix DocumentId class, add operator<<() for QDebug.
Mark comments as done.
This gives a bunch of warnings like
src/engine/idutils.h:48:43: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] return *(reinterpret-cast<DocId*>(arr));
Were these before...?
Updated function name.
Updated title and summary.
With this it is the third time I am completely changing the title and summary. When will it be too much? Or should I create a new patch everytime there's a change in approach?
This is to make @adridg happy. The real fun starts, when you take a look at the stack of this.