Version: 3.1.0 (using KDE 3.1.9) Compiler: gcc version 3.2.3 20030228 (Debian prerelease) OS: Linux (i686) release 2.4.19-jb-preempt-w4l When I copy files via fish:// (doesn't matter which direction) the file date/time are not preserved. 'scp -p' preserves them all right. This makes it very difficult to compare directories on foreign hosts to local versions because you don't know which files are newer, as soon as you copied or moved some of them. Thanks,
I have no idea why Konqueror didn't preserve the KDE version I use, but here it is again: I'm using CVS from Feb 25th, 2003 on Debian unstable. I would have tried a more recent snapshot but they don't compile here ...
for the moment it's impossible to preserve the date and time since non of the ioslaves fish:// ftp:// support changing the date and time of a file after it's been transferred.
For FTP, the command MDTM (or MTDM?) is supposed to accomplish this. Would it be very hard to implement this?
Basically, copying files always means fresh timestamps. So this is not a bug, it is exactly as intended. Try copying with cp or scp or konqueror locally, it's the same there. kio_fish can't suddenly make things work differently. Moving is a different thing, there timestamps should be preserved, but the KIO subsystem doesn't support that yet across different protocols/ hosts. You may want to file a bug report against kio in general if you need that. If you are using some syncing tool to compare directories, I strongly advise you to use that to do the initial transfer as well. I am doing a lot of syncing myself and have found rsync and unison two valuable tools.
Subject: Re: kio-fish does not preserve file date/time On Sun, Jul 27, 2003 at 07:08:35PM -0000, J
When a file is MOVED, it's access times should be kept. When it's COPIED, you create a copy (the cp and scp default behaviour, without the preserve switches), so it has a different a/c/mtime. Again, the problem is that KIO doesn't support this yet.
As Thiago says, "cp -a"/"scp -p" is not a plain COPY. As for rsync, really do try unison, it is a great synchronization tool which uses librsync for data transfer, it is bidirectional and has conflict resolution.
so please implement unison in konqueror. i will open a wish for that.
a) this is probably dup of bug# 89377 (or more likely that is a dup of this one, as this is bigger), b) Midnight Commander DOES preserve time for me when copying files over scp, maybe the inspiration of how they do it. Matej
Why has this bug been marked resolved? The non-preservation of timestamps makes using these protocols to update a remote directory very difficult. Take for example, someone working on one file in three places: make file1 on local host copy file1 -> remote host 1 edit file1 on remote host 1 copy file1 -> remote host 2 Which one holds the the newest? localhost, remotehost1 or remotehost2? The truth is that it is on remotehost1; but the timestamps will tell you that it is on remotehost2. I can't see any justification for saying that copying a file should alter the timestamp. A copy should be just that - a copy.
Yes marking this as invalid is wrong. The idea of KIO::copy is to emulate cp -a, i.e. to preserve mtime; it already does so on the local file system. #79937 and #55804 are about implementing the support for this in KIO (which I'm about to do), this one is for kio_fish in particular, once kio supports it.
*** Bug 89377 has been marked as a duplicate of this bug. ***
Note that the behaviour is different for uploads than for downloads. In Konqueror 3.5.8, when files are copied via ssh from a remote host to local, the file's date is the date that the original file was created on the remote host. However, if the file is then copied from local to a different remote host, the new file's date is today. The inconsistency leads to even more confusion.
This bug seems to be a dupe of bug 55804 as that bug addresses the issue for all protocol types, not just fish.
*** This bug has been marked as a duplicate of bug 55804 ***
If I move a file via fish using copy, the file date is preserved. If I move it via CUT and PASTE, the file date gets set to now. This is unexpected, so it is a bug.
Tstaerk, this bug was marked as dupe, not closed. Please add your comments and use case to bug 55804. Thanks. *** This bug has been marked as a duplicate of bug 55804 ***