trackerd uses O_NOATIME, but fruitlessly

Bug #312365 reported by jepler
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GLib
Fix Released
Wishlist
glib2.0 (Ubuntu)
Fix Released
Wishlist
Ubuntu Desktop Bugs
tracker (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: tracker

$ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

$ apt-cache policy tracker | head -2
tracker:
  Installed: 0.6.6-0ubuntu3.8.04.1

trackerd intends to use the O_NOATIME flag when opening files to index, in order to preserve file timestamps (see http://mail.gnome.org/archives/tracker-list/2008-April/msg00030.html describing changes in version 0.6.3 of tracker). However, not all open() calls to files to be indexed have the O_NOATIME, so the st_atime of the file is updated anyway.

Steps to reproduce:
* start a graphical login session with trackerd enabled; trackerd should be started automatically in the default gnome session
* strace -ff -e open `pidof trackerd` 2>&1 | grep test-file-name
* (in another terminal) cd Desktop
* echo test-file-contents > test-file-name
* Inspect the sequence of open() syscalls issued by trackerd

Expected behavior: each open() of test-file-name includes the 'O_NOATIME' flag
Actual behavior: at least one open() lacks the 'O_NOATIME' flag

Partial strace output:
[pid 13383] stat("/home/jepler/Desktop/test-file-name", {st_mode=S_IFREG|0664, st_size=19, ...}) = 0
[pid 13383] open("/home/jepler/Desktop/test-file-name", O_RDONLY) = 33
[pid 13383] open("/home/jepler/Desktop/test-file-name", O_RDONLY|O_NOATIME) = 33

This caused a difficult-to-diagnose problem in mutt where mbox files in ~/mail/ did not reliably appear as folders containing "new mail". Workarounds seem to include forbidding trackerd to index in ~/mail or (reportedly) using mutt's check_mbox_size option.

Revision history for this message
jepler (jepler) wrote :

The test strace command I gave in the original report was incorrect. It should be:
  strace -ff -e open -p `pidof trackerd` 2>&1 | grep test-file-name
(original lacked "-p")

xdgmime used fopen to get bytes to determine the file's mime type. this patch changes it to use open() so that the O_NOATIME flag can be given.

Revision history for this message
A. Walton (awalton) wrote :

Thanks for pointing this out. I have forwarded the GIO component of this bug upstream and attached a patch for review. Tracker will need to be updated to make use of the new QUERY_INFO_FLAG.

Changed in glib2.0:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package glib2.0 - 2.19.4-0ubuntu1

---------------
glib2.0 (2.19.4-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    GIO:
    - Use O_NOATIME when sniffing mimetypes (lp: #312365)
    - Add a convenience method to check if a GSimpleAsyncResult is valid
    Bugs fixed:
    - 560676 function access for g_threads_supported
    - 565905 There is no g_context_group_set_translation_domain
    - 564210 SUN Studio 12 has supported visibility attribute
    - 565136 GObject's "notify" signal parameters are wrong in gtk-doc
    - 565831 error in interface creation sample
    - 566348 g_file_open_tmp uses the wrong g_mkstemp on win32
    - 566064 Add NOATIME flag to query_info_flags
    - 566170 g_async_result_verify_source_object

 -- Sebastien Bacher <email address hidden> Tue, 06 Jan 2009 10:49:41 +0100

Changed in glib2.0:
status: Triaged → Fix Released
Revision history for this message
jepler (jepler) wrote :

I don't have Jaunty to test, but are you sure this fixes the bug? tracker 0.6.6 on ubuntu hardy uses a bundled copy of xdgmime to find mime types, not the GIO routine. As far as I know, only the post-0.6.6 SVN version uses GIO.

Changed in glib:
status: Unknown → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote :

Looking at the attachments in this bug report, I noticed that "use O_NOATIME in an xdgmime routine" was not flagged as a patch. A patch contains changes to an Ubuntu package that will resolve a bug and this attachment is one! Subsequently, I've checked the patch flag for it. In the future when submitting patches please use the patch checkbox as there are some Launchpad searches that use this feature. Thanks for your contribution jepler!

Changed in glib:
importance: Unknown → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.