[tracker/nb274498] tracker-writeback: Do not touch unsupported files
- From: JÃrg Billeter <juergbi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [tracker/nb274498] tracker-writeback: Do not touch unsupported files
- Date: Tue, 26 Jul 2011 13:56:32 +0000 (UTC)
commit 503f9d70d324fe389f31e81c79b9f9aff49c4317
Author: JÃrg Billeter <j bitron ch>
Date: Tue Jul 26 15:55:47 2011 +0200
tracker-writeback: Do not touch unsupported files
Fixes NB#274498.
src/tracker-writeback/tracker-writeback-file.c | 138 ++++++++++++------------
1 files changed, 71 insertions(+), 67 deletions(-)
---
diff --git a/src/tracker-writeback/tracker-writeback-file.c b/src/tracker-writeback/tracker-writeback-file.c
index 60175b5..0aa18f7 100644
--- a/src/tracker-writeback/tracker-writeback-file.c
+++ b/src/tracker-writeback/tracker-writeback-file.c
@@ -123,15 +123,6 @@ tracker_writeback_file_update_metadata (TrackerWriteback *writeback,
return FALSE;
}
- /* Copy to a temporary file so we can perform an atomic write on move */
- tmp_file = get_tmp_file (file);
- if (!g_file_copy (file, tmp_file, 0,
- NULL, NULL, NULL, NULL)) {
- g_object_unref (file);
- g_object_unref (tmp_file);
- return FALSE;
- }
-
mime_type = g_file_info_get_content_type (file_info);
content_types = (writeback_file_class->content_types) (TRACKER_WRITEBACK_FILE (writeback));
@@ -146,66 +137,79 @@ tracker_writeback_file_update_metadata (TrackerWriteback *writeback,
g_object_unref (file_info);
- if (retval) {
- g_message ("Locking file '%s' in order to write metadata", row[0]);
-
- tracker_file_lock (file);
-
- urls[0] = row[0];
-
- tracker_miner_manager_ignore_next_update (tracker_writeback_get_miner_manager (),
- "org.freedesktop.Tracker1.Miner.Files",
- urls);
-
- /* A note on IgnoreNextUpdate + Writeback. Consider this situation
- * I see with an application recording a video:
- * - Application creates a resource for a video in the store and
- * sets slo:location
- * - Application starts writting the new video file.
- * - Store tells writeback to write the new slo:location in the file
- * - Writeback reaches this exact function and sends IgnoreNextUpdate,
- * then tries to update metadata.
- * - Miner-fs gets the IgnoreNextUpdate (sent by the line above).
- * - Application is still recording the video, which gets translated
- * into an original CREATED event plus multiple UPDATE events which
- * are being merged at tracker-monitor level, still not notified to
- * TrackerMinerFS.
- * - TrackerWriteback tries to updte file metadata (line below) but cannot
- * do it yet as application is still updating the file, thus, the real
- * metadata update gets delayed until the application ends writing
- * the video.
- * - Application ends writing the video.
- * - Now TrackerWriteback really updates the file. This happened N seconds
- * after we sent the IgnoreNextUpdate, being N the length of the video...
- * - TrackerMonitor sends the merged CREATED event to TrackerMinerFS,
- * detects the IgnoreNextUpdate request and in this case we ignore the
- * IgnoreNextUpdate request as this is a CREATED event.
- *
- * Need to review the whole writeback+IgnoreNextUpdate mechanism to cope
- * with situations like the one above.
- */
-
- retval = (writeback_file_class->update_file_metadata) (TRACKER_WRITEBACK_FILE (writeback),
- tmp_file, values, connection);
-
- /*
- * This timeout value was 3s before, which could have been in
- * order to have miner-fs skip the updates we just made, something
- * along the purpose of IgnoreNextUpdate.
- *
- * But this is a problem when the event being ignored is a CREATED
- * event. This is, tracker-writeback modifies a file that was just
- * created. If we ignore this in the miner-fs, it will never index
- * it, and that is not good. As there is already the
- * IgnoreNextUpdate mechanism in place, I'm moving this timeout
- * value to 1s. So, once writeback has written the file, only 1s
- * after will unlock it. This synchronizes well with the 2s timeout
- * in the miner-fs between detecting the file update and the actual
- * processing.
- */
- g_timeout_add_seconds (1, file_unlock_cb, g_object_ref (file));
+ if (!retval) {
+ /* module does not support writeback for this file */
+ g_object_unref (file);
+ return FALSE;
}
+ /* Copy to a temporary file so we can perform an atomic write on move */
+ tmp_file = get_tmp_file (file);
+ if (!g_file_copy (file, tmp_file, 0,
+ NULL, NULL, NULL, NULL)) {
+ g_object_unref (file);
+ g_object_unref (tmp_file);
+ return FALSE;
+ }
+
+ g_message ("Locking file '%s' in order to write metadata", row[0]);
+
+ tracker_file_lock (file);
+
+ urls[0] = row[0];
+
+ tracker_miner_manager_ignore_next_update (tracker_writeback_get_miner_manager (),
+ "org.freedesktop.Tracker1.Miner.Files",
+ urls);
+
+ /* A note on IgnoreNextUpdate + Writeback. Consider this situation
+ * I see with an application recording a video:
+ * - Application creates a resource for a video in the store and
+ * sets slo:location
+ * - Application starts writting the new video file.
+ * - Store tells writeback to write the new slo:location in the file
+ * - Writeback reaches this exact function and sends IgnoreNextUpdate,
+ * then tries to update metadata.
+ * - Miner-fs gets the IgnoreNextUpdate (sent by the line above).
+ * - Application is still recording the video, which gets translated
+ * into an original CREATED event plus multiple UPDATE events which
+ * are being merged at tracker-monitor level, still not notified to
+ * TrackerMinerFS.
+ * - TrackerWriteback tries to updte file metadata (line below) but cannot
+ * do it yet as application is still updating the file, thus, the real
+ * metadata update gets delayed until the application ends writing
+ * the video.
+ * - Application ends writing the video.
+ * - Now TrackerWriteback really updates the file. This happened N seconds
+ * after we sent the IgnoreNextUpdate, being N the length of the video...
+ * - TrackerMonitor sends the merged CREATED event to TrackerMinerFS,
+ * detects the IgnoreNextUpdate request and in this case we ignore the
+ * IgnoreNextUpdate request as this is a CREATED event.
+ *
+ * Need to review the whole writeback+IgnoreNextUpdate mechanism to cope
+ * with situations like the one above.
+ */
+
+ retval = (writeback_file_class->update_file_metadata) (TRACKER_WRITEBACK_FILE (writeback),
+ tmp_file, values, connection);
+
+ /*
+ * This timeout value was 3s before, which could have been in
+ * order to have miner-fs skip the updates we just made, something
+ * along the purpose of IgnoreNextUpdate.
+ *
+ * But this is a problem when the event being ignored is a CREATED
+ * event. This is, tracker-writeback modifies a file that was just
+ * created. If we ignore this in the miner-fs, it will never index
+ * it, and that is not good. As there is already the
+ * IgnoreNextUpdate mechanism in place, I'm moving this timeout
+ * value to 1s. So, once writeback has written the file, only 1s
+ * after will unlock it. This synchronizes well with the 2s timeout
+ * in the miner-fs between detecting the file update and the actual
+ * processing.
+ */
+ g_timeout_add_seconds (1, file_unlock_cb, g_object_ref (file));
+
/* Move back the modified file to the original location */
g_file_move (tmp_file, file,
G_FILE_COPY_OVERWRITE,
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]