tracker-miner-fs: Fall back if no modification date is found

There are paths in GIO (mainly EACCES errors during stat) that we
may get returned no error, but a GFileInfo that does not contain
all the requested information. Cases that may trigger this are:

  - Odd permission patterns. I was able to reproduce with a
    directory from another user with 744 permissions, stat would
    then cause EACCES with the directory contents.
  - Other kernel reasons to deny access (SELinux, AppArmor, etc).

This used not to be a problem, as only modification/access times
missing used to be relevant to us, and we dealt with them as int64_t
so we silently dealt with the returned 0, thus we set those times
as being the "epoch". Now we try to get a GDateTime, and get a NULL
pointer instead, causing crashes in its manipulation.

As we need files to have a modification time for our comparisons
during crawling, make these files have again a fictional date set
in the epoch to avoid the crash and make the machinery work with
these files.

src/miners/fs/tracker-miner-files.c

@@ -2079,7 +2079,10 @@ miner_files_process_file (TrackerMinerFS      *fs,
 
 	is_directory = (g_file_info_get_file_type (file_info) == G_FILE_TYPE_DIRECTORY ?
 	                TRUE : FALSE);
+
 	modified = g_file_info_get_modification_date_time (file_info);
+	if (!modified)
+		modified = g_date_time_new_from_unix_utc (0);
 
 	if (!create && !is_directory) {
 		/* In case of update: delete all information elements for the given data object
@@ -2200,8 +2203,11 @@ miner_files_process_file_attributes (TrackerMinerFS      *fs,
 		                          NULL, NULL);
 	}
 
-	/* Update nfo:fileLastModified */
 	modified = g_file_info_get_modification_date_time (info);
+	if (!modified)
+		modified = g_date_time_new_from_unix_utc (0);
+
+	/* Update nfo:fileLastModified */
 	time_str = g_date_time_format_iso8601 (modified);
 	tracker_resource_set_string (resource, "nfo:fileLastModified", time_str);
 	g_date_time_unref (modified);