GNOME Bugzilla – Bug 696163
Overwriting an file using the MTP backend in nautilus fails with "could not send object info."
Last modified: 2013-08-16 03:42:50 UTC
Trying to overwrite a file fails with "could not send object info" in LIBMTP_Send_File_From_File() instead of prompting the user for an action. Perhaps because the backend doesn't check for an existing file and raise G_IO_ERROR_EXISTS in do_push()? I compared the mtp backend to the obexftp backend and found that it doesn't handle all the possible error cases. Is that on purpose? If not, I'll attach a patch to handle the error cases properly.
Patches always welcome :-) Does Nautilus actually try to delete the file if it gets G_IO_ERROR_EXISTS?
(In reply to comment #1) > Patches always welcome :-) > > Does Nautilus actually try to delete the file if it gets G_IO_ERROR_EXISTS? Yep, it does: copy_move_file() in libnautilus-private/nautilus-file-operations.c: /* Conflict */ if (!overwrite && IS_IO_ERROR (error, EXISTS)) { gboolean is_merge; ConflictResponseData *response; [...] response = run_conflict_dialog (job, src, dest, dest_dir); [...] So, if the operation returns G_IO_ERROR_EXISTS, the file name conflict dialog is popped up. In either case, returning the correct error is part of the API, so it should be returned appropriately. :)
It's not quite that simple. It re-issues the copy with the OVERWRITE copy flag set, which the backend then needs to respect. Right now I ignore the copy flags. It's actually easier for me to deal with this - as this change is simpler when done on top of the patch for bug 696016.
Created attachment 239368 [details] [review] Support overwrite in do_push
(In reply to comment #3) > It's not quite that simple. It re-issues the copy with the OVERWRITE copy flag > set, which the backend then needs to respect. Right now I ignore the copy > flags. > Yeah, that's what I meant. Nautilus tries to overwrite based on the user's input in the conflict resolution window. I didn't notice that do_push ignores the copy flags, though. > It's actually easier for me to deal with this - as this change is simpler when > done on top of the patch for bug 696016. That bug and its parents are great. Thanks for taking care of this!