GNOME Bugzilla – Bug 325861
gnome_vfs_async_xfer reports wrong GnomeVFSXferProgressInfo in the callback for http method
Last modified: 2006-01-12 13:57:19 UTC
With gnome-vfs 2.12, doing a gnome_vfs_async_xfer over http of multiple files I got this internally: Breakpoint 3, count_each_file_size_one ( rel_path=0x919d238 "/bugzilla.gnome.org/bugzilla-mostfreq.xml", info=0x91c05e0, recursing_will_loop=0, data=0xb7cf5010, recurse=0xb7cf5018) at gnome-vfs-xfer.c:706 706 if (call_progress_often (params->progress, params->progress->progress_info->phase) == 0) { (gdb) p *info $1 = {name = 0x91d9270 "bugzilla-mostfreq.xml", valid_fields = 9793, type = GNOME_VFS_FILE_TYPE_REGULAR, permissions = 0, flags = GNOME_VFS_FILE_FLAGS_NONE, device = 0, inode = 0, link_count = 0, uid = 0, gid = 0, size = 5899, block_count = 0, io_block_size = 0, atime = 1136466983, mtime = 1136466017, ctime = 0, symlink_name = 0x0, mime_type = 0x91d4d80 "text/xml", refcount = 1, reserved1 = 0x0, reserved2 = 0x0, reserved3 = 0x0, reserved4 = 0x0, reserved5 = 0x0} Where all the info is correct. However with gnome-vfs 2.13.4 I got this: Breakpoint 3, count_each_file_size_one ( rel_path=0x9f63b80 "/bugzilla.gnome.org/bugzilla-mostfreq.xml", info=0x9f9b678, recursing_will_loop=0, data=0xb7c2b010, recurse=0xb7c2b018) at gnome-vfs-xfer.c:706 706 if (call_progress_often (params->progress, params->progress->progress_info->phase) == 0) { (gdb) p *info $1 = {name = 0x9fabad0 "bugzilla-mostfreq.xml", valid_fields = GNOME_VFS_FILE_INFO_FIELDS_TYPE, type = GNOME_VFS_FILE_TYPE_REGULAR, permissions = 0, flags = GNOME_VFS_FILE_FLAGS_NONE, device = 0, inode = 0, link_count = 0, uid = 0, gid = 0, size = 0, block_count = 0, io_block_size = 0, atime = 0, mtime = 0, ctime = 0, symlink_name = 0x0, mime_type = 0x0, refcount = 1, reserved1 = 0x0, reserved2 = 0x0, reserved3 = 0x0, reserved4 = 0x0, reserved5 = 0x0} with every field set to zero. The impact of these is big, because the GnomeVFSXferProgressCallback progress_sync_callback function get zero values for the GnomeVFSXferProgressInfo *info. This impacts almost every download dialog in GNOME (async xfer updating a progress bar based on the xferinfo). I'd need to test this with non-http method to locate the problem.
*** Bug 325860 has been marked as a duplicate of this bug. ***
Created attachment 56857 [details] [review] Proposed (untested) patch Maybe you could test whether this patch helps? To me it looks like the directory visit doesn't demand enough fields.
Confirming, raising priority, milestoning to GNOME 2.14.
Created attachment 56889 [details] [review] Proposed patch This one makes GnomeVFS destroy the request after getting the file info, not before.
Created attachment 56890 [details] [review] This time without #define garbage
last patch works for me and fixes the critical warning in bug-buddy it should be applied to 2.12 and 2.13, possibly 2.10, as they all crash by default now on critical warnings
*** Bug 325626 has been marked as a duplicate of this bug. ***
I commited the second patch. Chris, what about the first one? Is it still valid?
While it is not relevant for this patch, I think it actually modifies the GnomeVFS behavior in a reasonable way. The passed-in info_options seems to be applied to all subdirectory visits, and the caller's callback may well be interested in these file infos. There is IMHO no reason to potentially request less than the GNOME_VFS_FILE_INFO_DEFAULT.
*** Bug 326092 has been marked as a duplicate of this bug. ***
Manny: GNOME_VFS_FILE_INFO_DEFAULT is zero, so the first patch makes no difference. However, it makes the code cleaner imho, so I'm applying it.