Your best friend for file transfer.

Fetch application logoFetch

time/date stamp (9 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 12 years ago by chopp
  • Latest reply 12 years ago from Jim Matthews
  • chopp Member

    Hi,

    I've used fetch for a little while and like the new mirroring feature, but it doesn't quite work the way I thought it would. Maybe someone can shed light on this. First, I've noticed that ver. 4 does not get the time/date stamp in correct. I have many files which download from a RedHat Linux box and end up with date modified as Jan 1, 1904 on my mac
    (OS 8.6). It's not all the time, but just
    sometimes. Of course this messes up directory mirroring because it can't tell which files are new and which are old. Maybe if this is
    fixed, the problems I've had with mirroring not maintaining the most recent versions will straighten themselves out. Has anyone else had this problem? thanks for any help...

    DC

    Posted 12 years ago #

  • Jim Matthews Administrator

    I haven't seen that myself. You might double-check to make sure that your Mac's clock is correct. If you can find a file that always downloads with the wrong date I'd love to see the contents of the Fetch Transcript window.

    Jim Matthews
    Fetch Softworks

    Posted 12 years ago #

  • Boodlums Member

    I haven't tested with 4.0, but in 3.0.3 I was never satisfied with Fetch's [non-]handling of datestamps (upload/download UNIX/Mac).
    So I always use Zmodem in ProTERM to transfer important files (like my Web content) between my ISP and my Mac.

    Are file datestamps handled better now?

    thanks,
    -Walter

    Posted 12 years ago #

  • Jim Matthews Administrator

    Fetch 4.0 tries to set the modification date of downloaded files to the modification date of the file on the server (unless the file's in a format, like MacBinary, that includes a modification date).

    Jim Matthews
    Fetch Softworks

    Posted 12 years ago #

  • Boodlums Member

    Originally posted by JimMatthews:

    Fetch 4.0 tries to set the modification date of downloaded files to the modification date of the file on the server (unless the file's in a format, like MacBinary, that includes a modification date).

    What about uploads? Will the file be written to the UNIX server with the same modification date as on my Mac?

    Posted 12 years ago #

  • Jim Matthews Administrator

    No, there's no provision in the FTP protocol for changing the modification date of a remote file. I've thought of optionally changing the modification date on the local version to match the date of the newly-uploaded remote file (i.e. bring it up to the present), but that's the only way I can think of to keep them in sync.

    Jim Matthews
    Fetch Softworks

    Posted 12 years ago #

  • Boodlums Member

    Originally posted by JimMatthews:

    No, there's no provision in the FTP protocol for changing the modification date of a remote file. I've thought of optionally changing the modification date on the local version to match the date of the newly-uploaded remote file (i.e. bring it up to the present), but that's the only way I can think of to keep them in sync.

    Jim Matthews
    Fetch Softworks

    Ugh, no! That would be horrific.

    I guess I can use Fetch for downloads and for remote editing (where the current time applies to both local and remote), but uploads I will have to continue doing via Zmodem in ProTERM.

    No way to 'touch' dates via FTP I take it?

    thanks,
    -Walter

    Posted 12 years ago #

  • Boodlums Member

    Oh, and if not FTP, how about sftp or scp -- do any of those support datestamping uploaded files?

    thanks,
    -Walter

    Posted 12 years ago #

  • Jim Matthews Administrator

    I don't think sftp or scp support setting the modification date of a file on the server; you'd have to open up a shell over ssh.

    Jim Matthews
    Fetch Softworks

    Posted 12 years ago #

Topic closed

This topic has been closed.