A False Positive

While I was struggling with the Clementine project trying to understand how the library works underneath, I noticed that there were some debug prints in the console:

21:43:16.817 DEBUG LibraryWatcher:351 "/home/ponza/Music/test.mp3" created
21:57:50.402 DEBUG LibraryWatcher:333 "/home/ponza/Music/test.mp3" changed
21:57:50.402 DEBUG LibraryWatcher:521 "/home/ponza/Music/test.mp3" metadata changed

I thought that those prints could have been a good clue to discover where the file's information was modified. Thus, I went through the library files looking for the library watcher. I noticed that the Library class is the one that manages the LibraryWatcher class. Indeed, it connects LibraryBackend with the signals (QT) emitted by LibraryWatcher (Observer pattern). The library watcher lives on a background thread (BackgroundThreadFactory) an it scans the library whenever the Library class requires it. If some event happens (e.g. a new file added) the watcher notifies the event to the LibraryBackend that accesses the internal database. I went through all of these processes of monitoring files trying to find out where the modification to the file's information would have made and I was not able to discover it. Indeed, this modification does not happen.

In the meantime, I noticed that one of my assumption regarding the behavior of the database was right: Clementine saves all the information and meta-information of every file in the internal database. However, I also realized that each time an event is fired by the LibraryWatcher it re-reads the information from the file. I guess that this is done to avoid data inconsistency between internal database and the filesystem (e.g. an external program that changes the tags of a file).

Since I was banging my head on the wall because of the fact that I was not able to find out how those modification were made, I decided to do a little "experiment". I modified the Song::InitFromFile method forcing it to load the current date as creation date and modification date. In doing so, I discovered that there were no modifications made by the software, every file was showing the current date. Thus, I thought of a bug in QT in QDateTime but it was not the case. Indeed, QDateTime gives three accessors to get the creation date, the modification date and the last access date. In other words, it maps the timestamps you get in command line from stat:

Access: 2011-10-21 11:13:16.501303538 +0200
Modify: 2008-01-14 15:29:12.000000000 +0100
Change: 2011-10-21 11:13:16.117303530 +0200

QTDateTime reports the Access date as the creation date and Modify as the modification date. Since both creation date and modification date are refreshed with the current date when a file is modified (e.g. a tag is updated) by the filesystem itself and QT just reports those dates, there is no way to solve the bug: the modification date will be always updated together with the creation date. Moreover, the Issue 1815 cannot be considered a bug. Rather, it is just a misunderstanding due to the context in which information is shown. It is likable that the bug's reporter made the same error as I made, that is, I considered those dates as they were related to the creation and modification of entries in the internal database.

In the end, I can claim "I found a bug in the bug".