Opened 22 years ago
Last modified 11 years ago
#308 closed Bug report
Overwrite if newer doesn't work
Reported by: | leerqbasic | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | Other |
Keywords: | Cc: | leerqbasic, matti3, mgordon78, Tim Kosse | |
Component version: | Operating system type: | ||
Operating system version: |
Description
I'm using Filezilla 2.1.6, and it seems that when you set
the "Overwrite if newer" option at the File Transfer
screen, it doesn't work. Local files of e.g. 26-4 will just
overwrite remote files of 24-4.
This is very annoying when uploading directories, as
ALL files are uploaded and not only those which have
been changed.
Change History (7)
comment:1 by , 22 years ago
comment:2 by , 22 years ago
when I tried this feature (using filezilla client+server), I noticed
that when the client asks what to do with the file, the remote
file has always a time of 0:00. So I thought maybe this was
the reason why it doesn't work.
I tried a different server and then the remote filedate was
correctly displayed in the filezilla client and the file did not get
transferred, however, the log shows a critical transfer error..
comment:3 by , 20 years ago
This is still an issue in ver 2.2.8a when communicating
between Win XP and linux server.
comment:4 by , 19 years ago
This bug report has been closed due to inactivity and has possibly
already been solved.
You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).
comment:5 by , 19 years ago
Logged In: NO
Overwrite if newer is still not fixed. I just installed both the
latest server (0.9.8a) and client (2.2.13c). For test I connected
through localhost, created an account with all rights enabled
on some dir and did the following:
- download a file from server (notice that the file on serverside
does not show any timestamp (date is shown though))
- the time of the local file is wrong, the date is correct
- upload the downloaded file back to server
- overwrite dialog is shown, but:
1) local file still has incorrect time of course (in my case
always 2am)
2) the server file does not have a time value as indicated in
userinterface, although it surely has one! 0am is shown/used
instead
- ofcourse, when pressing "overwrite if newer", the file will be
uploaded, because the times are incorrect
- from then on, times are shown correctly on server
- it's not done yet: now download the SAME file again from the
server
- "overwrite if newer" still overwrites (ie gets downloaded), as
the local time is still not correct (server is)
- now both local and remote file has correct time, and the
overwrite if newer works correctly from then on
this is my experience, please fix
mattie
P.S.: filesystem in testcase is NTFS
comment:6 by , 19 years ago
eh, got logged out? you may always contact me for further
testing. Filezilla is a great client but this is one of my pet
issues ;)
comment:7 by , 19 years ago
I've just tested the overwrite if newer feature, it seem to
work perfectly.
However, you will get problems if at least one of the
following condition is met:
- Local or server time not set correctly
- Server in different timezone than client
- Server not reporting filedates/times correctly or in an
unknown format
The first two problems can be worked around by using the
Site Manager, there you can set a time offset on the
Advanced page.
To detect the offset, upload a file and compare the local
time with the remote timestamp. The difference is the
desired offset you will have to enter in the Site Manager.
Some comments on the test(s) you made:
Files older than 6 month (or a year, not sure right now) do
not report their time, instead the year is added in file
listings, which is ommited in younger files.
"the time of the local file is wrong, the date is correct"
This looks like you're using the preserve timestamp option.
Note that this only works for downloads, there's no
standardized FTP command yet to set the remote timestamp.
Whoops, the two dates I mentioned as an example should be
switched. Files of 24-6 will overwrite remote files of 26-6.