if background image set to path on removable storage, image should be copied to local storage

Bug #725337 reported by Alex Chiang
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Fix Committed
Low
Unassigned

Bug Description

Not 100% sure if this counts as a papercut, as I'm not sure it is trivially fixable. However, this is a good a place to start as any to file the bug for tracking purposes, and it can always be moved against the proper package.

Steps:
 1. connect USB storage which has some photos
 2. Select a photo and open it to view
 3. Set it as wallpaper
 4. Shutdown
 5. Remove the USB storage
 6. Boot up

Expected behaviour
 Wallpaper should be set.

Actual behaviour
 Blank background.

Explanation:
a) in step 3, we do not actually copy the image from the USB key to the main storage. In fact, we simply set a gconf key (desktop->gnome->background->picture_filename) that defines the background image as a path on the USB key.

b) so when the key is removed in step (5) and rebooted in step (6), the path to the background image is no longer valid, and that is why we do not see it upon restart.

c) in fact, even if the key is present (ie, skip step 5 and perform steps 4 and 6), we still get a blank background.

The reason for this is because the normal desktop starts *before* the USB key is mounted, so the path to the background image is invalid. Nautilus cannot find the path, and we get the empty background.

Now if Unity-2D is in the picture, and we enter the Dash homescreen, we *might* see the background image, but only if the USB key was present during boot. This is because the Dash home screen logic occurs *after* the USB key is mounted, so now the path to the image *is* valid. Unity reads the path, it works, and we see the image. Somehow, Unity caches the image somewhere, because it remains even after the key is removed.

This is very confusing behavior. As a developer, I think "duh, you're setting a path to an image on removable storage, so when that goes away, of *course* your image won't work". However, it is slightly troubling that it doesn't work even if the USB key is present during boot, due to the timing of when drives are mounted vs. when nautilus looks at the paths.

This could all be fixed simply by ensuring that whenever we set a background image, we always copy it to local storage, and setting the gconf key accordingly.

Revision history for this message
Vish (vish) wrote :

Thanks for the detailed bug report. But we already have Bug #344228 which has been fixed by upstream as you've mentioned (If wallpaper is not in local pictures directory, it will just be copied.). :-)

This will land with other g-c-c 3 changes, or if someone works on backporting the change to g-c-c 2

Changed in hundredpapercuts:
status: New → Fix Committed
importance: Undecided → Low
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.