(noticed same behavior with openssh 3.8p1 via Cygwin on W2K and openssh 3.7.1p2 on a Linux machine - both cases copying files FROM a Linux machine running 3.7.1p2) Attempted to copy a file from a Linux machine with a (legal) pre-1970 date (don't ask me WHY I have files with those dates :) ) using scp -p to preserve the date. In both cases the file arrived intact, but had a date in January 2038 (which I recognized as the highest possible 32-bit value).
Created attachment 588 [details] Truncate pre-epoch timestamps in scp, add debugging Does the rcp/scp protocol even permit times before the epoch? If not, the best we can do is truncate the date to the epoch as per the attached patch. I added a bit more detail in the debugging: $ ./scp -vp /mnt/tmp/file localhost:/tmp/ [...] File mtime -100000 atime 1080785365 Sending file timestamps: T0 0 1080785365 0 Sending file modes: C0664 2323 file
Comment on attachment 588 [details] Truncate pre-epoch timestamps in scp, add debugging Please make sure rcp gets this too when you commit
Created attachment 1294 [details] equivalent change for rcp This is the equivalent change to rcp. I'm not 100% sure it's right because the format is signed in rcp rather than unsigned in scp and rcp uses stb.st_atimespec.tv_sec rather than stb.st_mtime.
Target 4.8
This has been committed and will be in 4.8. Thanks.
Fix shipped in 4.9/4.9p1 release.