No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • Timestamps

    The FTP servers I work with do not support touching files on the server. This leads to an impossible situation.

    Using the option "Ignore timezone differences" resolves the time delta when comparing files in the folder view; however, it shows the real time and just factors in the timezone differences when deciding if the files are the same. If you then touch the local files, their time is set without adjusting for the timezone difference. So, after touching the local file, the local and server files show the exact same time and the timezone adjustment calls them unequal by a number of hours equal to the timezone difference.

    In BC2, on the More tab of the session settings, there was a Timezone Adjustment option that let you set a number of hours to adjust local or remote files. This feature worked very well because it adjusted the time of remote files both for display and when touching local files. Unlike the "ignore" feature, this made the time stamps look the same in the folder view, and caused touch to work usefully. This feature is now missing.

    The option to automatcially touch local files when uploading to an FTP server is still not implemented. Of course, I guess it won't help without either a change to the way touch works or bringing back the Timezone Adjustment feature.

    BTW, the ftp sites are hosted web sites, so I have no control over the ftp server configuration.


  • #2

    Thanks for bringing this up. I'll discuss it with our developers to try handling this situation in Cirrus.
    Chris K Scooter Software


    • #3

      In case you haven't noticed it yet, we added a "Timezone" field to the FTP profiles, so you can enter the timezone the servers are actually in and it will adjust things accordingly. Once we get the touch-after-copy in it will use the same settings.

      We'd like to do away with the BC2-style timezone adjustment in favor of including explicit timezones per resource (FTP server, network drive), etc. If you set the timezone correctly and do an explicit touch to copy the timestamps from the server to the local disk does it work correctly?
      Zoë P Scooter Software


      • #4
        Ah-ha! That looks like it will work fine.

        So, I guess the feature to auto-detect the server time was working because otherwise the comparison setting "Ignore timezone differences" would not have worked? So, why would setting the server time-zone from auto-detect to a specific zone change the way file times are handled?


        • #5
          "Ignore timezone differences" ignores any integral hour difference up to 23-hours different. It doesn't change the times that are displayed and it doesn't actually know anything about the real timezones involved, so it can get tripped up by timezones with 1/2 hour differences.

          The profile-specific timezone setting makes Cirrus convert the timestamps from the original timezone to the local timezone before displaying and comparing them.

          For example, say you're in in California (PST) editing a file on a server in New York (EST) at 6am PST. The normal timezone-ignoring behavior would show the file's last modified time as 9am, since that's what time the server thinks it is. If you turned on "Ignore timezone differences", the two times would be considered a match anyway. If Cirrus can auto-detect the server's timezone (using the SITE ZONE command) or if you set the profile's timezone to EST specifically, Cirrus will instead show the FTP file's last modified time as 6am.
          Zoë P Scooter Software


          • #6
            1) Using FTPS, the dates on the server show correctly but all of the times are 00:00:00. When I download a file, it's also set to 00:00:00 on my local pc.

            2) When I upload a file, the MDTM command fails:

            30-Nov-2007 09:21:20 Sent> STOR JabberError.gif
            30-Nov-2007 09:21:20 Recv> 150 Opening BINARY mode data connection for file JabberError.gif.
            30-Nov-2007 09:21:21 Recv> 226 File store complete. Data connection has been closed.
            30-Nov-2007 09:21:21 Sent> MDTM 20070517070835 JabberError.gif
            30-Nov-2007 09:21:21 Recv> 550 File or directory not found.

            I'm using Build 441 on WinXP against the file storage at Fastmail.

            (Sorry I haven't had any time in the previous 1.5 months to test the latest builds until now.)


            • #7

              1) There's no way for me to confirm that this affects FastMail's server, but many FTP servers will show this. They include "MM/DD HH:MM" for recent files and "MM/DD/YY" for older files, so we have to assume the time is midnight. At some future point we're planning on changing the display so it leaves the time blank in this case, but downloads would still get that time.

              There are multiple ways to handle this in BC/Cirrus:
              A) Turn on "Use MLSD" and turn off "Recursive [-R]" in the LIST Options. MLSD always includes a full timestamp, and as I said in the other post, FastMail doesn't support recursive listings, so you're not missing anything.
              B) Check the "Complete timestamps [-T]" LIST option. On servers that support this option, they will always return a full "MM/DD/YY HH:MMP:SS" timestamp. FastMail doesn't support this either, but for servers with -R support this is the best option.
              C) Check the "Fetch incomplete timestamps" Misc option on the Listings page. This makes Cirrus ask for the full timestamp of any file that only includes MM/DD/YY. It works almost everywhere, but it's much slower since it's sending an extra command per file for a good percentage of the files in the directory listing.

              For FastMail you should be able to just check the "Use MLSD command" and uncheck all the other "LIST options" commands.

              2) FastMail also doesn't support setting the last modified times on files. The next release will reintroduce the "Touch local files when uploading" option to help with this. I know the FastMail guys are using a customized version of some open source Unix FTP server, so you might have luck asking them to add support for either "MDTM <timestamp> <filename>" or "MFMT <timestamp> <filename>", either of which would allow the touch to succeed.
              Zoë P Scooter Software


              • #8
                Craig, thanks for the info. I just tested the MLSD option and it does indeed return the correct file times from Fastmail.


                • #9
                  I'm not sure if this is a regression from build 441 to 442, but the MLSD command is not currently working for every file at Fastmail. Cirrus returns 00:00:00 when a file has a timestamp of 0:39 (for example) but there's not a problem if the timestamp is between 12:00 and 23:59.

                  It might be a bug with Fastmail's ftp server, but I wanted to report this because I thought that the MLSD command worked with Fastmail in build 441 (but I'm not 100% sure).

                  A second problem is that Cirrus is returning 00:00:00 for all top-level folders (even ones that have a timestamp of 16:24 for example).

                  I think that I've tried every possible combination of Cirrus options but the only one that works 100% correctly is "Fetch Incomplete Timestamps".


                  • #10

                    You should have "Use MLSD command" checked and "Recursive [-R]" unchecked. If I do that the timestamps work fine.

                    In 441 if "Use MLSD Command" was checked it always took precedence over the other options. In 442 I changed it so if "Recursive [-R]" is also checked it will use "LIST -R" instead and fall back to MLSD if the server doesn't return a recursive listing. That would have the effect of showing the top-level directories without full timestamps and the directories below them with it.
                    Zoë P Scooter Software