Opened 17 years ago

Last modified 6 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 Changed 17 years ago by leerqbasic

Whoops, the two dates I mentioned as an example should be
switched. Files of 24-6 will overwrite remote files of 26-6.

comment:2 Changed 16 years ago by matti3

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 Changed 15 years ago by mgordon78

This is still an issue in ver 2.2.8a when communicating
between Win XP and linux server.

comment:4 Changed 14 years ago by Tim Kosse

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 Changed 14 years ago by anonymous

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 Changed 14 years ago by matti3

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 Changed 14 years ago by Tim Kosse

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.

Note: See TracTickets for help on using tickets.