Touch error

[goodeye]

Hi,

I'm having trouble sync'ing file timestamps over ftp in BC3, compared to BC2 behavior.
I hope to sort the time differences themselves out, but for now there seems to be a bug:

When I touch the remote files, I get this error:

4/24/2009 4:47:46 PM Sent> MDTM 20090228061811 about.html
4/24/2009 4:47:46 PM Recv> 200 Command OK.
4/24/2009 4:47:46 PM Sent> MDTM 20090227060849 faqs.html
4/24/2009 4:47:46 PM Unable to set last modified time of ftp:..../about.html: Command OK.
etc
(5 files touched, 5 commands and responses like this, interleaved but not symmetrical with the order of the BC3 error message)

My FTP server logs show the command and response as ok.

When I do a full refresh, the files times are changed, so the command did go through. (The time zones aren't what I expect, but that's a separate issue, as I said.)

BC3 3.1.2 build 10221

Thanks,
Bob
P.S. This may belong in Folder Compare or FTP forums instead - please move it if you wish.

[Zoë]

Hi Bob,

I'll have to check on Monday, but I'd guess that your server is returning the wrong result code for the MDTM command. BC's pretty strict about that, so if it's expecting a '250' and your server returns '200' it will show the behavior you're seeing. It's really a bug in the server, but if you let me know which FTP server software you're running I can change BC so it accepts this case.

[goodeye]

Thanks - let me upgrade my server first before you 'loosen' your response handling.

It's Titan FTP Server, v5.25, which is a few years old. They're up to 7.02.
In 7.01 Feb 2009, there's this:
Fixed: MDTM would fail to return a valid reponse for 200

I'll let you know if that meant they fixed it to return 250, or still return 200.

Thanks,
Bob

[goodeye]

Hi,
I upgraded my Titan FTP Server to v7.02, with no difference in the MDTM response.
I'm pinning down both sides of the timestamps, but I'll still keep this thread about the response code behavior.

I learned that MDTM to set time is not technically correct, but I appreciate that you support it as a common behavior.

Titan now accepts MFMT, but they fail on the decimal point and following digits. I posted a ticket that they should accept it. The right answer is for me to wait for that fix.

In the meantime, if you would like to get things consistent, I noticed that the BC3 file transfer sequence that sends MDTM accepts 200; but the touch command sending MDTM does not (which is what started this thread)

Since this is a bit of red herring, assuming they'll fix MFMT, I'm happy with however you want to proceed:
Since setting time with MDTM is not spec'ed, there is no spec'ed response code. If I also post a ticket to Titan about MDTM, would you prefer a 250 response, or a 213 response similar to MFMT? Their server is great, but their docs are poor. Their docs say MDTM responds with 213, which it doesn't. If I pester them, I could point to the 213 as what they should do, if you agree with it.

Or, since it's unspec'ed anyway, do you want to just accept the 200 like you already do with the file transfer sequence?

Thanks for the attention to detail!
Bob

[Zoë]

I've already made the change to accept 200; it will be in the next release. We're actually expecting 253; the 250 was off the top of my head when I wrote the original post.

I've also changed the MFMT command so it doesn't send the milliseconds (the decimal). The current MFMT RFC doesn't include them in the examples, so it'll be safer this way.

[goodeye]

Thanks, that's fine with the MDTM 200, just to get on with it. I don't see a 253 anywhere.

I see what you mean on the MFMT RFC examples - it's vague. The example doesn't have them, and the 'time-val' isn't explicitly spec'ed in this rfc. So they really should accept it, but omitting it from BC3's point of view is ok (assuming you only compare to the second...)