sftp does not set timestamps

[webograph]

Binary package hint: gvfs

when copying or moving files to a directory mounted over sftp, the time stamps are not preserved.

this affects both hardy and intrepid (in hardy, it was tested with a patched version of nautilus hence that version used to forget timestamps on copy anyway). in both cases, i tested it locally and everything was preserved as it should be.

moreover, when moving, nautilus first displays the correct time stamp and only on refreshing shows the wrong updated one.

as timestamps can be considered considered important information, i suggest this bug be treated as "losing data without notice".

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

[webograph (webograph)]

to reproduce the problem in intrepid:

* create a file "a", remember its timestamp
* places -> connect to server, via ssh, to an ssh server (in my case, openssh 4.3p2-5~bpo.1)
* copy the file to folder on the server using nautilus
--> at latest after a refresh, the timestamp on the file will be different from that of the original file

sames goes for moving instead of copying.

[Sebastien Bacher (seb128)]

the issue is similar to bug #336761 or http://bugzilla.gnome.org/show_bug.cgi?id=527339

[Sebastien Bacher (seb128)]

using scp on a command line has a similar issue

[Antonis Kanouras (akanouras)]

FWIW, also occurs in Jaunty.

[Alex N. (a-nox)]

This still happens in Ubuntu Precise. This bug is a serious issue if you want to copy images over sftp and your date information get lost.

[pva (pieter-valkenburg)]

I also want to note this is a serius bug for timestamp related file synchronisation. (Multi node home directory synchronisation over secure SFTP)

Reproduce:
SFTP already mounted in nautilus (automatic by gigolo)

>cd ~;touch -d '1 May 2012 10:22' test.txt
>stat test.txt
>cp test.txt .gvfs/SFTP on <FQDN>/<PATH>/
>stat .gvfs/<FQDN>/<PATH>/test.tst

all tme staps ar changed (normal behavior cp)

>touch -d '1 May 2012 10:22' .gvfs/SFTP on <FQDN>/<PATH>/test.tst

---> ERROR: touch: setting times of `.gvfs/SFTP on <FQDN>/<PATH>/bug.txt': Operation not supported

[Alecz20 (alexguzu)]

When using scp, you can give the -p switch that will preserver timestamps.

It would be nice if this would be the default behavior for sftp as well.
Alternatively, a config file for sftp would be acceptable.

I agree about the importance of the issue. Especially with images and videos. If you lose the timestamp... you might lose it forever.

Workaround: copy from command line using the -p parameter (not the -P)

[david6 (andrew-dowden)]

This was partially fixed in Ubuntu 12.04 LTS (desktop).

Puch / Puill:

If you copy from a remote Ubuntu platform, then the timestamp is preserved. But if you copy too, then only some platforms honour the timestamp (otherwise it is set to 'now' by the receiving platform).

Tested today with full patched Ubuntu 12.04.2 LTS desktop, server, and Ubuntu 13.04 desktop (all 64-bit):

 - Copying from 13.04 desktop to 12.04 desktop ( Ok )
 - Copying from 13.04 desktop to 12.04 server ( timestamp replaced, with 'now' )

 - Copying from 12.04 desktop to 13.04 desktop ( Ok )
 - Copying from 12.04 desktop to 12.04 server ( Ok, but new directories have timestamp of 'now' )

This should be fixed, and be consistent. Either as default behaviour, or from SFTP config. file.

[david6 (andrew-dowden)]

Repeated testing using Nautilus, and SFTP to server.

Does NOT honour timestamp, for files or directories.

[david6 (andrew-dowden)]

Able to resolve, using 'scp -rp' at command line.

Unable to resolve from any GUI app, that (in theory) uses SCP or SFTP.

[mprotic (mprotic)]

Sorry I'm an idiot, I changed status to Fix Released while browsing. How the f**k am I alllowed to change this status, anyway ?

Plese revert to Confirmed

[nesuribe (nesuribe)]

I can confirm this still happens in 14.04, even when copying from 14.04 to another 14.04.

Please revert status to Confirmed

[Rocko (rockorequin)]

Yes, I can confirm it's still an issue in 16.04 using gvfs:amd64 1.27.4-1ubuntu1. It's almost the seven year anniversary of the bug, too!

[Michael Dooley (mdooley)]

I can also confirm that this issue still exists in 16.04 using gvfs:amd64
1.28.2-1ubuntu1~16.04.1 Using MATE and Caja to SFTP both to and from server.

[david6 (andrew-dowden)]

Related, and possible NOT worth raising as its own bug.

Renaming a zero-length (semaphore) file in Nautilus does NOT change its time/date stamp.

Tested/verified today with fully updated Ubuntu 16.04 LTS, and 'Nautilus' ('Files' v3.14.3).

[Julian Rüger (jr98)]

I posted a bounty for the underlying gvfs bug:

https://www.bountysource.com/issues/23459433-gvfs-should-set-file-attributes-properly

If you want this fixed, please consider contributing.
Thanks and sorry for spam ;)

[Michael Dooley (mdooley)]

I note that this issue does not exist in Ubuntu-MATE 19.10 alpha (September 16, 2019) using gvfs 1.42.0-1ubuntu1 and Caja to SFTP both to and from a server. Files can be copied without changing their timestamps.