GNOME Bugzilla – Bug 749788
gvfs-copy does not preserve timestamp
Last modified: 2015-05-25 21:39:03 UTC
When using gvfs-copy --preserve from a MTP device to local, the timestamp is not preserved. touch "localfile" --reference="MTP file" works ok. Linux Mint 17 (based on Ubuntu 14.04), device Samsung Galaxy S4 I9505. $ apt-show-versions gvfs gvfs:amd64/trusty-updates 1.20.3-0ubuntu1 uptodate gvfs:i386/trusty-updates 1.20.3-0ubuntu1 uptodate $ apt-show-versions libmtp-common libmtp-common:all/trusty 1.1.6-20-g1b9f164-1ubuntu2 uptodate Reported and confirmed here: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1175947
Created attachment 303875 [details] [review] mtp: Copy mtime when pulling Copy the modification timestamp after copying a file from the device. Normally, this would be done in the copy fallback path, but if pull() is implemented, it must also copy metadata.
Phillip, is it possible to set the modification time when copying to the device (e.g. in do_push())?
As far as I can tell, no, there's no attribute you can set to update the modification time. Also, your change unconditionally copies the modification time, which isn't normal semantics. I never did this because it was never clear to me what '--preserve' means semantically, in terms of which properties to carry over and which not to. No other backend respects it either, so I had no guidance. I suppose it's fine to just copy the modification time and not worry about anything else, but you do need to make it conditional.
Review of attachment 303875 [details] [review]: Needs to respect the G_FILE_COPY_ALL_METADATA flag to decide whether to do it or not.
(In reply to Philip Langdale from comment #3) > As far as I can tell, no, there's no attribute you can set to update the > modification time. > > Also, your change unconditionally copies the modification time, which isn't > normal semantics. I never did this because it was never clear to me what > '--preserve' means semantically, in terms of which properties to carry over > and which not to. No other backend respects it either, so I had no guidance. > I suppose it's fine to just copy the modification time and not worry about > anything else, but you do need to make it conditional. Modification time is always copied (for guidance you can usually use the local file implementation). To see this: $ gvfs-info -w /etc/os-release Settable attributes: standard::symlink-target (bytestring) time::access (uint64, Keep with file when moved) time::access-usec (uint32, Keep with file when moved) time::modified (uint64, Copy with file, Keep with file when moved) time::modified-usec (uint32, Copy with file, Keep with file when moved) unix::gid (uint32, Keep with file when moved) unix::mode (uint32, Copy with file, Keep with file when moved) unix::uid (uint32, Keep with file when moved) Writable attribute namespaces: metadata (string, Copy with file, Keep with file when moved) xattr (string, Copy with file, Keep with file when moved) xattr-sys (string, Keep with file when moved) Because time::modified is marked "Copy with file", it means that it must always be copied. If G_FILE_COPY_ALL_METADATA is specified, then all settable attributes should be copied. I'm not sure if there're any other interesting attributes that should be maintained when pulling from a device.
So that seems weird, in-so-far as it's not POSIX. When you 'cp' a file, the modification time is the time that you copied it.
(In reply to Philip Langdale from comment #6) > So that seems weird, in-so-far as it's not POSIX. When you 'cp' a file, the > modification time is the time that you copied it. There are many things about GIO that aren't POSIX-like :-) So is it OK to commit then?
(In reply to Ross Lagerwall from comment #7) > (In reply to Philip Langdale from comment #6) > > So that seems weird, in-so-far as it's not POSIX. When you 'cp' a file, the > > modification time is the time that you copied it. > > There are many things about GIO that aren't POSIX-like :-) > > So is it OK to commit then? Heh. Go ahead. Thanks for doing this.
Pushed to master as fee67ba4e7c8edaccc5e858a53effe03d79cf461 and gnome-3-16 as 81a4d39e4aaf61dd3f9f2f1390e1fdaceb3eb91c. Thanks for the review.