7 Replies Latest reply on Nov 29, 2007 3:16 PM by Newsgroup_User

    Anyone know a way to set a file date on Windows?

    Applied CD Level 1
      I’ve just finished a behavior that checks a remote server for updates to CD based PDFs and downloads on request. The behavior compares the local file date (either CD or HDD depending on whether a previous update has occurred) against the remote file date to determine if the download button should be displayed. My concern is that a PDF document uploaded to a server retains it’s original modification date as you’d expect …however… on the download directFTP xtra assigns the current date to the downloaded file. In 99% of all cases this will still work fine, but imagine this scenario:

      File version 1.0 starts on the server with a modification date of Nov 26th 2007
      File version 2.0 is created on Nov 27th 2007 but is not immediately uploaded
      On Nov 28th 2007 a user with version 0.0 runs our software and accepts the download of version 1.0 where it is locally stored with a file date of Nov 28th 2007
      On Nov 29th 2007 file version 2.0 is uploaded to the server, however, since the file has not been changed the file modification date remains Nov 27th 2007.
      On Nov 30th 2007 our user, now with file version 1.0 runs our software, however, the local file (version 1.0) has a modification date of the 28th while the remote file (version 2.0) has a modification date of the 27th and so our software does not recognize that the remote file is newer.

      Confusing? … yeah, sorry about that. One obvious solution is to just make sure the uploaded file’s modification date is the same as the actual date of upload, however, I’m counting on human nature for someone to screw that up. If it can be done, I think the best choice would be to set the local file date to match the server.
        • 1. Re: Anyone know a way to set a file date on Windows?
          Level 7
          BuddyAPI has baFileDate() that will let you set the file date.
          • 2. Re: Anyone know a way to set a file date on Windows?
            Applied CD Level 1
            Thanks Mike, but I think baFileDate is read only, I don't see a way to set the file date with that command.

            myFileDate = baFileDate(fileName,DateFormat,TimeFormat) where the date and time formats are strings
            • 3. Re: Anyone know a way to set a file date on Windows?
              Level 7
              Sorry- it is baSetFileDate() that will set it.

              -Mike
              • 4. Re: Anyone know a way to set a file date on Windows?
                Applied CD Level 1
                Very Cool. Thanks Mike.

                For anyone that’s curious, baSetFileDate is undocumented but it works as follows:

                errorCode = baSetFileDate(filePath, int Year, int Month, int Day, int Hour, int Minute, int Second)


                - Bob
                • 5. Re: Anyone know a way to set a file date on Windows?
                  Level 7

                  "Applied CD" <webforumsuser@macromedia.com> wrote in message
                  news:fikgnn$3b6$1@forums.macromedia.com...
                  > Very Cool. Thanks Mike.
                  >
                  > For anyone that?s curious, baSetFileDate is undocumented but it works as
                  > follows:
                  >
                  > errorCode = baSetFileDate(filePath, int Year, int Month, int Day, int
                  > Hour,
                  > int Minute, int Second)
                  >
                  >
                  > - Bob

                  Hi,
                  are you sure you want to use this method?

                  How do you handle different timezones?
                  What happens if the users clock is off-set?

                  I needed to use an MD5 checksum and seperate description files for version
                  numbers to do something like this reliably.

                  Richard.


                  • 6. Anyone know a way to set a file date on Windows?
                    Applied CD Level 1
                    Hi Richard,

                    My FTP server reports the file date/time in GMT so my behavior includes an optional correction to user local time. Anticipating that some servers might return server local time rather than GMT the behavior can still calculate the offset to user local time if provided the timezone of the server. For anyone that’s curious, the following code will provide the GMT offset for the local user in minutes:

                    GMToffset = baResRegNumber("System\CurrentControlSet\Control\TimeZoneInformation", "ActiveTimeBias", 0, "hkey_local_machine")

                    Of course this only works if the system clock is correctly set, however, I’ve found that an incorrectly set clock creates havoc with a number of applications so we’re not in bad company … besides, most CDs with PDF content can’t update themselves at all, I figure we’re ahead of the game by being able to update content in all but the most extreme cases of poor computer configuration.

                    Early in this project I considered using a small text file on the server that included a list of updateable files and their current versions and a matching list on the user’s HDD. This approach certainly has some advantages; timezone correction isn’t an issue, no worries about inconsistent responses from different types of FTP servers, etc… The server text file could also include path information to the source files which would allow the source files to be relocated if necessary. You could even include parameters similar to a *.ini or *.cfg file that would allow modification of a CD’s behavior after it has been released.

                    The downside to the server text file and the reason we choose to go the other way is maintenance. I wanted an end result that partially web savvy clients could self maintain. It seemed much easier to tell a client that has at least heard of FTP to simply upload a new version of their catalog, manual, price list, whatever, and the updates for his/her customers would be automatic, adding an extra hurdle by requiring a properly formatted text file maintained by the client seemed dangerous and a deal breaker. Of course we haven’t deployed this yet so the jury is still out. If our clients choose not to do their own updates and ask us to host instead then the text file may have been the better way to go.

                    - Bob
                    • 7. Re: Anyone know a way to set a file date on Windows?
                      Level 7

                      "Applied CD" <webforumsuser@macromedia.com> wrote in message
                      news:fimmbb$hcf$1@forums.macromedia.com...
                      > Hi Richard,
                      >
                      > My FTP server reports the file date/time in GMT so my behavior includes an
                      > optional correction to user local time. Anticipating that some servers
                      > might
                      > return server local time rather than GMT the behavior can still calculate
                      > the
                      > offset to user local time if provided the timezone of the server. For
                      > anyone
                      > that?s curious, the following code will provide the GMT offset for the
                      > local
                      > user in minutes:
                      >
                      > GMToffset =
                      > baResRegNumber("System\CurrentControlSet\Control\TimeZoneInformation","ActiveTim
                      > eBias",0,"hkey_local_machine")
                      >
                      > Of course this only works if the system clock is correctly set, however,
                      > I?ve
                      > found that an incorrectly set clock creates havoc with a number of
                      > applications
                      > so we?re not in bad company ? besides, most CDs with PDF content can?t
                      > update
                      > themselves at all, I figure we?re ahead of the game by being able to
                      > update
                      > content in all but the most extreme cases of poor computer configuration.
                      >
                      > Early in this project I considered using a small text file on the server
                      > that
                      > included a list of updateable files and their current versions and a
                      > matching
                      > list on the user?s HDD. This approach certainly has some advantages;
                      > timezone
                      > correction isn?t an issue, no worries about inconsistent responses from
                      > different types of FTP servers, etc? The server text file could also
                      > include
                      > path information to the source files which would allow the source files to
                      > be
                      > relocated if necessary. You could even include parameters similar to a
                      > *.ini or
                      > *.cfg file that would allow modification of a CD?s behavior after it has
                      > been
                      > released.
                      >
                      > The downside to the server text file and the reason we choose to go the
                      > other
                      > way is maintenance. I wanted an end result that partially web savvy
                      > clients
                      > could self maintain. It seemed much easier to tell a client that has at
                      > least
                      > heard of FTP to simply upload a new version of their catalog, manual,
                      > price
                      > list, whatever, and the updates for his/her customers would be automatic,
                      > adding an extra hurdle by requiring a properly formatted text file
                      > maintained
                      > by the client seemed dangerous and a deal breaker. Of course we haven?t
                      > deployed this yet so the jury is still out. If our clients choose not to
                      > do
                      > their own updates and ask us to host instead then the text file may have
                      > been
                      > the better way to go.
                      >
                      > - Bob
                      >

                      Maybe for a simple application it might work... but I found that it becomes
                      a nightmare to maintain very quickly.
                      There are just too many things not under your control.... file dates and
                      times is just one of them.

                      Every FTP server out there has a different way of reporting dates, sizes,
                      filenames.
                      Once you make a choice for one, you're basically stuck. For years probably.

                      Most applications/Cd's update themselves over HTTP these days, FTP is too
                      inflexible.


                      R.