Review Request: Don't hang when determining MIME type of corrupted files

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102391/#review5872
-----------------------------------------------------------


Thanks Peter and Miroslav. The analysis looks correct, the pre-read part of the patch looks good. I'm just wondering about using Unbuffered. If someone installs a mimetype definition with multiple rules trying to match some bytes after the 2K limit, then all this seeking-and-reading back and forth will be very slow, in unbuffered mode (since neither cache will be used).

- David


On Aug. 20, 2011, 5:21 p.m., Peter Penz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102391/
> -----------------------------------------------------------
> 
> (Updated Aug. 20, 2011, 5:21 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Summary
> -------
> 
> If KMimeTypeRepository::findFromContent() tries to determine MIME from a file that cannot be read, such as on a corrupted optical disc, a read attempt is made in KMimeMagicMatch::match() for every available rule, resulting in UI hangs (e.g. file dialogs, dolphin) for tens of minutes (see https://bugs.kde.org/show_bug.cgi?id=280446 for more details).
> 
> I've submitted this patch here on behalf of Miroslav ?os, who has submitted the bug-report and also has written the patch.
> 
> 
> This addresses bug 280446.
>     http://bugs.kde.org/show_bug.cgi?id=280446
> 
> 
> Diffs
> -----
> 
>   kdecore/services/kmimetype.cpp 955bf62 
>   kdecore/services/kmimetyperepository.cpp 6ff3d16 
> 
> Diff: http://git.reviewboard.kde.org/r/102391/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Peter
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110821/7c2bbe69/attachment.htm>