Summary: | Baloo crashes when file has timestamp 0 | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | Anton Kreuzkamp <akreuzkamp> |
Component: | Baloo File Daemon | Assignee: | Christoph Cullmann <christoph> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | aspotashev, christoph, me, pinak.ahuja, steve |
Priority: | NOR | Keywords: | drkonqi |
Version: | 5.16.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/baloo/628daced19b88d0c537736a14aea3287a4662609 | Version Fixed In: | 5.27 |
Sentry Crash Report: |
Description
Anton Kreuzkamp
2015-11-12 12:20:32 UTC
Hmm, this is strange. Somehow the timeinfo object doesn't have any mTime information. You can check which file it is by running: balooshow 68743270854821892 in the terminal Heh, that looks like a hint! :) [anton@kdab_akrp ~]$ balooshow 68743270854821892 The fileID is not equal to the actual Baloo fileID This is a bug GivenID: 68743270854821892 ActualID: 0 GivenINode: 16005540 ActualINode: 0 GivenDeviceID: 2052 ActualDeviceID: 0 No index information found [anton@kdab_akrp ~]$ find /home/anton -inum 16005540 /home/anton/Backups/N9 - 15-08-23/Nokia N9 The inode belongs to a directory. [anton@kdab_akrp ~]$ ls -la Backups/N9\ -\ 15-08-23/ [...] drwxr-xr-x 29 anton anton 4096 Jan 1 1970 Nokia N9 hehe... strange, but it seems those things happen in a file system :D So mtime and ctime can be zero due to file system screw ups, we should probably remove those asserts. This is annoying. The mtime and ctime really shouldn't be 0. Anyway, marking as confirmed. See https://git.reviewboard.kde.org/r/128887/ time 0 is perfectly valid, this should never have been asserted. *** Bug 362333 has been marked as a duplicate of this bug. *** Git commit 628daced19b88d0c537736a14aea3287a4662609 by Christoph Cullmann. Committed on 11/09/2016 at 16:48. Pushed by cullmann into branch 'master'. allow ctime/mtime == 0 Fix that baloo is instant killed by any file with timestamp 0. (which is OK and can easily happen after unpacking some zip/tar/..) REVIEW: 128887 M +17 -0 autotests/unit/engine/documenttimedbtest.cpp M +0 -2 src/engine/documenttimedb.cpp M +0 -3 src/engine/writetransaction.cpp http://commits.kde.org/baloo/628daced19b88d0c537736a14aea3287a4662609 Fixed ;=) Thanks for pushing the fix. I see you didn't wait for the Shipit ;-) In any case, an mtime/ctime value of 0 isn't illegal - it means 0 time units after the unix epoch. Is there any reason the asserts were there other than to just crash on potential filesystem bugs? > In any case, an mtime/ctime value of 0 isn't illegal - it means 0 time units after the unix epoch. Is there any reason the asserts were there other than to just crash on potential filesystem bugs?
I guess there are there because of some misunderstanding that 0 is not allowed.
But given that any tar archive might contain such timestamps, it is very bad to assert on that.
|