When I was using Ubuntu 12.04 fallback (gnome panel), I could copy a file from the remote-host (source) to the local host (recipient) using Nautilus SSH and the file would have the identical date-stamp, both remote and local. Now that I use MATE 16.04 and Caja instead of Nautilus, I am unable to copy a file using a local SSH connection without the local file having its’ date-stamp changed to the time when I copied it. Is there a way to keep the date stamps unchanged when using Caja?
Using rsync, I can copy a file from a network connection and it will have the same time stamp on the local system.
Thanks for any help you can offer.
I wonder if Nemo (file manager) would do this.
Thanks v3xx, but I’m really interested in the caja/ssh difficulty. I suspect that it may involve gvfs (the virtual filesystem) rather than just caja.
Looking over the web hasn’t done me much good in solving this problem. From my experience with 12.04 nautilus, I know it has been done before. Thanks anyway.
2 Likes
I installed Nemo locally and it behaves like caja in that the local file has a time/date of the transfer, not that of the original file. Thanks - it was worth investigating.
I’m now curious whether Nautilus from 16.04 also behaves this way.
If this is from gvfs, do you consider this a regression?
I started an existing bare metal install of Unity 16.10 and managed to initiate an SFTP connection to check whether nautilus could copy a test file without changing the properties - nope. The time-date stamp was the time of copying.
I’ll reinstall 12.04 on a server and client (to test) if you think that might be helpful in some way. I don’t know how to check for a gvfs regression however. That will have to go on my list of to-do’s.
This appears to be a long standing bug. See -
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/332646
I thought that I’d read something about this when using MATE 14.04.
edit: I’ve posted information on this bug at launchpad and hope to see progress in time.
3 Likes