----------------------------------------------------------- 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 > >
