The fix above seems to cover one case, but there's another that I just stumbled upon. The standard::copy-name attribute might not be set by the gvfs backend. In that case, currently, we fall back to edit-name attribute (and only if that's not set either -- to escaped URI). That causes the original undesired behavior that prompted this bug report: podcasts with non-unique file attributes/file names are unusable. Here's a real example:
$ gvfs-info http://computersciencepodcast.com/download-mp3/1/episode.mp3
display name: episode.mp3
edit name: episode.mp3
...
attributes:
...
standard::display-name: episode.mp3
standard::edit-name: episode.mp3
A fix for this particular case could be to fall back to the escaped URI and not to edit-name attr when copy-name is not set (see trivial patch for this below). However, that wouldn't really cure the real issue: it would be nice if Rhythmbox were robust against non-unique file attributes (ie, even if they are set) and file names on podcasts. Of course, this is a problem of podcast creators, but it might still make sense to work around it, esp. since in the canonical Rhythmbox user doesn't care about filenames of saved podcasts at all. A patch for this is not included but seems simple as well -- just always use the current fall-back-to-URI path for the local filename.
Patch to not fall back on edit-name when copy-name is null (for real example above):
The fix above seems to cover one case, but there's another that I just stumbled upon. The standard::copy-name attribute might not be set by the gvfs backend. In that case, currently, we fall back to edit-name attribute (and only if that's not set either -- to escaped URI). That causes the original undesired behavior that prompted this bug report: podcasts with non-unique file attributes/file names are unusable. Here's a real example: computerscience podcast. com/download- mp3/1/episode. mp3 :display- name: episode.mp3 :edit-name: episode.mp3
$ gvfs-info http://
display name: episode.mp3
edit name: episode.mp3
...
attributes:
...
standard:
standard:
A fix for this particular case could be to fall back to the escaped URI and not to edit-name attr when copy-name is not set (see trivial patch for this below). However, that wouldn't really cure the real issue: it would be nice if Rhythmbox were robust against non-unique file attributes (ie, even if they are set) and file names on podcasts. Of course, this is a problem of podcast creators, but it might still make sense to work around it, esp. since in the canonical Rhythmbox user doesn't care about filenames of saved podcasts at all. A patch for this is not included but seems simple as well -- just always use the current fall-back-to-URI path for the local filename.
Patch to not fall back on edit-name when copy-name is null (for real example above):
diff --git rhythmbox- 0.13.0git201008 19.orig/ podcast/ rb-podcast- manager. c rhythmbox- 0.13.0git201008 19.no-copy- name/podcast/ rb-podcast- manager. c 0.13.0git201008 19.orig/ podcast/ rb-podcast- manager. c 0.13.0git201008 19.no-copy- name/podcast/ rb-podcast- manager. c rInfo *data)
index a972490..d195684 100644
--- rhythmbox-
+++ rhythmbox-
@@ -769,14 +769,7 @@ download_podcast (GFileInfo *src_info, RBPodcastManage
if (src_info != NULL) {
data- >download_ size = g_file_ info_get_ attribute_ uint64 (src_info, G_FILE_ ATTRIBUTE_ STANDARD_ SIZE);
local_ file_name = g_file_ info_get_ attribute_ as_string (src_info, G_FILE_ ATTRIBUTE_ STANDARD_ COPY_NAME) ; info_get_ edit_name (src_info));
-
- if (local_file_name == NULL) {
- /* probably shouldn't be using this, but the gvfs http backend doesn't
- * set the copy name (yet)
- */
- local_file_name = g_strdup (g_file_
- }
}