file dating problem

[arjay]

(ALSO POSTED IN THE GENERAL SUPPORT FORUM)

When I upload files to FQ, which is in the Eastern time zone while I'm in Central, the file dates on my hard drive are automatically backward-dated to FQ's Eastern time. It's not a fatal problem or anything, but it does make my own file management confusing. FQ support told me a long time ago it was nothing they were doing, that it must be something in my computer or program. I'm on a Mac G3 Powerbook, using Dreamweaver 4, both for page creation and FTP uploading.

Any ideas? Thanks,
arjay

http://whiteartistscolony.org

[Rich]

Well, dreamweaver does not change timestamps during upload, at least not in the pc version. Can you give us an example of a file/date timestamp before and after the upload?

Rich

[Arthur]

It's the FTP server that sets the filedate to the time the file is uploaded (and it's set to the local timezone, EST in this case).

[edit]now that I read it a second time, I see that I have misread the question, sorry about that

[arjay]

Thanks for the help, Rich and arthur.

Rich, not sure what to respond to your request for an example. It's simply that a file's date on my own hard drive was, say, 10:21 before the upload, and jumps to 11:21 immediately after it.

And arthur, if I read your post correctly, you are saying that this is indeed what happens, as a function of FQ's server, which seems to contradict what Rich is saying, ie, that the PC version of DW does NOT change the file's timestamp.

I'm not real versed in this stuff, obviously, so maybe I'm missing something?

[Justin]

The server would not have any method for modifying your PC (that would be a *serious* flaw!) -- this is definitely a function of your client software.

The best thing I can recommend is to hit the documentation.

My guess is that DreamWeaver is (improperly) trying to 'sync' your local copy with the server's copy, assuming that the server's files are newer than your local copy. The problem is that it doesn't seem to be taking the time zone into consideration...

[arjay]

Justin - I think you hit it. Though I can't find any way to change it in DW. And, in fact, I see now that it has some value, synching the local and remote times that is. Maybe I'll just pretend I'm in the Eastern time zone myself and reset the clock on my computer!

Side bonus: maybe I'll start getting to meetings on time. :-)

Thanks for all the help.

[thor]

I use Dreamweaver, and I don't get that problem, but then again I don't use the synchronize function. Shouldn't do that on a straight upload.

What I DO get is an error that the file I am uploading is older than the file I am replacing on the FQ server. That, I assume is a funciton of time zone. (I also in Central).

It does mean, though that using the synchronizing process is a really BAD idea under certain specific circumstances. It could result in the loss of edits.

...I think

[Rich]

Like Thor, I usually just do puts for the files I have changed and don't use synchronize. I have also seen the "file is newer on server" message but usually just ignore it since I know there can never be any newer files on the server (in a single user environment).

I now suspect this message is a hint that there is a bug in their synchronization routines. I just searched their support site and while I didn't find any mention of an error in this area, I did find the following two rather conflicting statements:

This change in the modification date for the local file is necessary to the Site window's Synchronize command. Making this change to the local file's modification date is necessary so that Dreamweaver can, during the synchronization process, determine whether a local file has been updated since it was last transferred to the server.
Since there's no FTP call to get a server's time, Dreamweaver must create a directory and read the server's timestamp to establish the time difference. This allows Dreamweaver to complete functions that involve comparing files' timestamps.
The first technique is NOT "necessary" since the second technique is sufficient to determine what needs to be synchronized. In fact, implementing both techniques (without keeping track of who and why the local timestamp was changed) would guarantee synchronization errors. If they always change the local file's timestamp this would guarantee that the local file is *always* out-of-date when the 1st technique is used (unless, of course, the two computers just happen to be the same time.)

Rich
-- bug alert