Your best friend for file transfer.

Fetch application logoFetch

Mirroring doesn't handle time zones (4 posts)

This is an archived topic. The information in it is likely to be out-of-date and no longer applicable to current versions of Fetch.
  • Started 11 years ago by dand
  • Latest reply 11 years ago from Jim Matthews
  • dand Member

    When mirroring from a local folder to a remote server directory, Fetch compares dates on the remote files (eastern US time in my case) with modification dates of local files using presumably the local time (Japan time). Therefore, if I upload a file within 14 hours of editing it locally, then whenever I do a mirror of that directory that file gets uploaded even if it hasn't been edited.

    I read somewhere that the MDTM command is supposed to take care of time zones, so if Fetch uses the GMT modification date instead of the local time for local files then this problem should be fixed... maybe?

    Here's the transcript. The file in question, test.txt, shows as having modification date Jan. 6, 2003, 0:16PM in the Mac OS X 10.2.3 Finder (this is in Japan time). (I've cut some parts out.)

    ***Transcript***

    Fetch 4.0.3 System 0x1023 Serial FETCHED001-****-**** TR
    Connecting to pubbawup.net port 21 (1/6/03 0:10:58 PM)
    220 ProFTPD 1.2.6 Server (ProFTPD) [server.wwwroot3.net]
    ADAT
    500 ADAT not understood.
    USER dand@pubbawup.net
    331 Password required for dand@pubbawup.net.
    PASS
    230 User dand@pubbawup.net logged in.
    SYST
    215 UNIX Type: L8
    PWD
    257 "/" is current directory.
    MACB ENABLE
    500 MACB not understood.

    ......snip......

    PWD
    257 "/mirror_test" is current directory.
    PORT 192,168,0,4,189,6
    200 PORT command successful
    LIST -al
    150 Opening ASCII mode data connection for file list
    drwxr-xr-x 2 pubbawup pubbawup 4096 Jan 5 22:17 .
    drwxr-xr-x 15 pubbawup pubbawup 4096 Jan 5 22:17 ..
    -rw-r--r-- 1 pubbawup pubbawup 18 Jan 5 22:17 test.txt
    226 Transfer complete.
    MDTM test.txt
    213 20030105221702
    PORT 192,168,0,4,157,151
    200 PORT command successful
    STOR test.txt
    150 Opening ASCII mode data connection for test.txt
    226 Transfer complete.
    Upload complete at 1/6/03 0:18:20 PM
    CWD /mirror_test
    250 CWD command successful.
    PWD
    257 "/mirror_test" is current directory.
    PORT 192,168,0,4,57,207
    200 PORT command successful
    LIST -al
    150 Opening ASCII mode data connection for file list
    drwxr-xr-x 2 pubbawup pubbawup 4096 Jan 5 22:17 .
    drwxr-xr-x 15 pubbawup pubbawup 4096 Jan 5 22:17 ..
    -rw-r--r-- 1 pubbawup pubbawup 18 Jan 5 22:18 test.txt
    226 Transfer complete.
    PWD
    257 "/mirror_test" is current directory.

    Posted 11 years ago #

  • Jim Matthews Administrator

    You're right, the MDTM response is supposed to be in GMT, and that should eliminate time zone problems in mirroring.

    In this case the server's response to the MDTM command is that the file was last modified 20030105221702, or January 5, 2003, 10:17 PM GMT. Japan is 9 hours ahead of GMT, so that translates to January 6, 2003, 7:17 AM local time in Japan. So Fetch saw the copy of the file on your hard disk, with a local modification time of 12:16 PM, and it looked newer than the copy on the server.

    It looks like the server is using its local time (EST, 5 hours behind GMT and 14 hours behind Japan) in response to the MDTM command. That accounts for the 5 hour difference between the two modification times, and for the fact that the times in the file list (which are usually in local time) match the MDTM response. So either the server thinks its in GMT, or MDTM was implemented incorrectly. I would suggest contacting the server administrator about this.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 11 years ago #

  • dand Member

    Ah I see. Thanks for the quick response. I'll check with the server admin. So Fetch actually uses the GMT modification date on local files, correct? Good job :)

    Daniel

    Posted 11 years ago #

  • Jim Matthews Administrator

    Yes, Fetch uses the GMT modification date on local files, if it has a GMT modification date from the server. If GMT information is unavailable Fetch puts in a 23-hour fudge factor to account for the maximum possible difference between two time zones.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 11 years ago #

Topic closed

This topic has been closed.