Ubuntuone-Nautilus should not update file modification time to refresh the emblems

Bug #491777 reported by Roman Yepishev
56
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Ubuntu One Client
Fix Released
Medium
Roman Yepishev
ubuntuone-client (Ubuntu)
Fix Released
Medium
Roman Yepishev

Bug Description

Binary package hint: ubuntuone-client

static void ubuntuone_nautilus_update_meta which is a callback for get_metadata() call contains the following code:
 ...
  new_path = g_strdup_printf ("%s/%s", uon->managed, path);
  if (local && server && strcmp (local, server) == 0)
    g_hash_table_replace (uon->updated, new_path, new_path);
  else
    g_hash_table_replace (uon->needsupdating, new_path, new_path);
  utime (new_path, NULL);
}

This means that every time Nautilus visits the directory managed by ubuntuone all file modifications time are updated so that nautilus refreshes the emblems (this does not happen every time for the same directory, I suspect Nautilus caches the view somehow)

This is bad because of two issues arising from this:
1. The file modification times may be of some use to the applications performing simple checks 'reread-if-file-is-newer', as described in bug that I am not able to find at the moment (something about preserving the timestamps)
2. Which results from 1 - once file is "changed", Nautilus refreshes not only the emblem but the thumbnail as well. In case folder is full of "thumbnailable" files, the user experiences the following:
  1. Enter directory
  2. See all files with thumbnails and "synchronized" emblems
  3. Everything flickers
  4. All thumbnails are gone, emblems are updated
  5. Thumbnails start to pop-up gradually.
Since thumbnails dictate the size of the entry sometimes, such behavior results in file icons running back and forth until all the thumbnails are extracted. If user attempted to click file a he might click b instead, since there is a noticeable delay between initial folder display and thumbnail-free state.

I will attach the screencast displaying the problem once it gets to YouTube.

Additionally utime(path, NULL) is also called for every file that was mentioned in UploadStarted, UploadFinished, DownloadStarted and DownloadFinished signals.

This was not reported earlier because thumbnail support is broken in all versions including current PPA (See bug #479475). Once emblems processing is fixed, the bug reports describing the issue in question will start to appear.

Related branches

Revision history for this message
Roman Yepishev (rye) wrote :

The screencast displaying the problem is here: http://www.youtube.com/watch?v=ydb6KvfCKbM

Roman Yepishev (rye)
tags: added: nautilus-emblems
Changed in ubuntuone-client (Ubuntu):
status: New → Triaged
tags: added: desktop+
Changed in ubuntuone-client (Ubuntu):
importance: Undecided → Medium
importance: Medium → Undecided
assignee: nobody → Rodney Dawes (dobey)
Changed in ubuntuone-client:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Rodney Dawes (dobey)
Revision history for this message
Roman Yepishev (rye) wrote :

#nautilus at irc.gnome.org:

alex: Alexander Larsson
rtg: me

<rtg> alex, it listens to DBus signals that say 'File is being uploaded', 'File is downloaded' and changes the emblems on the files that are mentioned in those signals
<alex> even if those files are not currently shown by nautilus?
<rtg> alex, hm...
<alex> rtg: The correct way to implement something like that is to request the NautilusFileInfo object for the uri that change, if it exists, and if so call a "refresh" operation on it
<alex> rtg: such support doesn't exist, but i'd be happy getting patches to add it
<rtg> alex, so it is possible..
<rtg> alex, :'-(
<alex> rtg: its possible, but requires patches
<rtg> alex, it stores the data in internal GHashTable and adds the emblems when update_file_info is called from Nautilus, so no, emblems are not added for everything and everywhere
* giusef has quit (Segmentation fault)
<alex> does it add a ref to the file? or does it handle it going away?
<alex> Anyway, if you do that then you have a ref to the NautilusFileInfo already
<alex> then you can do this
<alex> just call nautilus_file_info_invalidate_extension_info()
<alex> on the object and you'll get update_file_info added again, just return the new fresh data there
<alex> What we don't currently have is a way to get a reference to a NautilusFileInfo object for a particular uri/path
<rtg> alex, okay, so this will not affect, say, thumbnails, right?
<alex> no, it will delete all extension info on the file and ask all registered info providers for fresh info
<alex> rtg: However, you should make sure that you don't keep a ref on the NautilusFile, since that would cause a leak in nautilus
<rtg> alex, okay, I will add this to our ext bug report. Since we can keep a ref to the NautilusFileInfo as the hash table value for the URI, we might call the *invalidate_extension_info. Ok, thanks for your help!
<alex> rtg: you should use a weak ref so you can remove the NautilusFileInfo from the hash when nautilus no longer monitors the file

Changed in ubuntuone-client (Ubuntu):
importance: Undecided → Medium
Roman Yepishev (rye)
Changed in ubuntuone-client:
status: Triaged → Fix Committed
Changed in ubuntuone-client (Ubuntu):
assignee: Rodney Dawes (dobey) → Roman Yepishev (rye)
Changed in ubuntuone-client:
assignee: Rodney Dawes (dobey) → Roman Yepishev (rye)
Roman Yepishev (rye)
Changed in ubuntuone-client (Ubuntu):
status: Triaged → Fix Committed
Roman Yepishev (rye)
Changed in ubuntuone-client:
status: Fix Committed → Fix Released
Changed in ubuntuone-client (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Philippe (philippe-rast) wrote :

I noticed that my files do not maintain the date of modification across my synced pc's. That is, imagine I work on file foo.dat at 14:30 and it is synced to u1. I go home, start the notebook at 18:50 and u1 synces that file it will have a new modification time saying I last changed that file at 18:50 - although I actually changed that file at 14:30.
Does this relate to this bug? And is this behavior intended? Doing the same thing in dropbox does not alter the time of last modification.

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.