MDTM Problem

[BrunoJ]

I am attempting to implement a remote backup solution using SyncBackSE as the client and FileZilla as the server. However, the file modified date is not being correctly set when uploading to the server. Here is a partial reformatted log:

<client> STOR WT10US.HST
<server> 150 Opening data channel for file transfer.
<server> 226 Transfer OK, compression saved 28260 of 32768 bytes (86.25%)
<client> MDTM 20071231163143 WT10US.HST
<server> 550 File not found
<client> MDTM /WT10US.HST
<server> 213 20080208210433

From what I see here, it appears the client is trying to set the file date using the MDTM command, the file date/time, and the file name. The server appears to be interpreting the file date as the file name. So, either the client's syntax is incorrect or the MDTM command is not completely implemented in Filezilla server. If it is the latter, can this be correctly implemented soon?

[botg]

Please read the specifications more carefully. MDTM is defined in RFC 3659 and can only be used to get the modification time, not to set it.

You want to use the MFMT command to set the modification time, as described in this IETF draft

[BrunoJ]

Please read the specifications more carefully. MDTM is defined in RFC 3659 and can only be used to get the modification time, not to set it.

You want to use the MFMT command to set the modification time, as described in this IETF draft

Thank you for the quick response. Unfortunately, I have no control over which command the client uses to set the time. I don't believe I will have much success in getting the client changed either. Their forum lists FileZilla as one of the server implementations where this problem exists and a few other server software packages are listed as not having the problem. Evidently they think they have implemented MDTM correctly since it works with those other packages. I'll try requesting a change there, but I suspect I'm just stuck in the middle.

[botg]

Please point them towards second 3.4 of RFC 3659, that one makes it clear that MDTM can not be used to set the timestamp.

[BrunoJ]

Please point them towards second 3.4 of RFC 3659, that one makes it clear that MDTM can not be used to set the timestamp.

Thanks again. Will do.

[petoulachi]

Hi,

I'm having the exact same problem with SyncBack. I know that using MDTM to set the date is no RFC compliant, but as the SyncBack's author doesn't admit that he don't use the correct command, could you please include in a next release the MDTM command to set the date ?

I'm a real fan of Filezilla, can't imagine using another FTP server, and I don't know free software to make backup by FTP, except Cobian backup (buggy) or SyncBack (works well except this problem).

Thanks in advance.

[botg]

No, why should I break the standard because there's some braindead developer out there that doesn't know how to read and understand RFCs?

Code: Select all

3.4.  MDTM Examples

   If we assume the existence of three files, A B and C, a directory D,
   two files with names that end with the string "ile6", and no other
   files at all, then the MDTM command may behave as indicated.  The
   "C>" lines are commands from user-PI to server-PI, the "S>" lines are
   server-PI replies.

      [...]
      C> mdtm file6
      S> 213 19990929003355
      C> MdTm 19990929043300 File6
      S> 213 19991005213102
      C> MdTm 19990929043300 file6
      S> 550 19990929043300 file6: No such file or directory.

   From that we can conclude that both A and B were last modified at the
   same time (to the nearest millisecond), and that C was modified 20
   days and several hours later.

   [...] there are
   files named both "file6" and "19990929043300 File6".  The
   modification times of those files were obtained.  There is no file
   named "19990929043300 file6".

SyncBack is broken, nothing else. BROKEN BY DESIGN. Don't use it.

[petoulachi]

Ok, maybe you know a software to make FTP backup then ?

I undestand your point of view, clearly, and I'm agree with you, but I'm in a deadlock.

[botg]

I do FTP backups using lftp and a couple of bash scripts.

[SkipRinPerth]

No, why should I break the standard because there's some braindead developer out there that doesn't know how to read and understand RFCs?

The use of MDTM to set file timestamp was implemented by a more than one software client and server software as the original RFC did not cover this. It was an ugly hack to do it that way and I do not dispute their is now a draft RFC to do it the "right" way, but there is still a case for supporting legacy ftp clients that were written BEFORE this draft RFC exisitence. Examples: Novell netdrive is a ftp client that has an option to support MDTM but no MFMT support. Ftp serv-u is a server that supports this.

It would be nice if there could be a deprecated option to use MDTM for old legacy software - netdrive software in particular. As far a I know this is the only client that meets my requirements of mounting an ftp connection as a microsoft windows network drive (it does WEBDAV too).

Sometimes older software needed to solve a problem before standards evolved. Netdrive is still a valuable old software unfortunately I doubt another release will be made. It would be kind of you to support older software with a deprecated feature. Open source that allows for better interoperability and legacy support is a good thing, even if its an ugly hack that's being supported. What do you think?

[botg]

The use of MDTM to set file timestamp was implemented by a more than one software client and server software as the original RFC did not cover this.

Simple solution: Add your own command, preferably starting with the letter X. But modifying an existing command in a way that blatantly breaks well established behavior and creates undefined behavior is just stupid.

Novell netdrive is a ftp client that has an option to support MDTM but no MFTM support.

Novell is a dinosaur, soon extinct. And don't get me started on what's wrong with "FTP drives", the protocol clearly has not been designed to be misused like that.

Ftp serv-u is a server that supports this.

Proprietary buyware, you simply pay them money to fix it. If you already have payed money and they still didn't fix this issue, bring it up with the courts (I believe there's some law that if you buy something broken, the vendor has to fix it). But don't complain here. If you buy a new car and the engine blows out on the first drive, you don't call the ministry of road and bridge building and complain to them.

[SkipRinPerth]

You want to use the MFMT command to set the modification time, as described in this IETF draft

It's a good idea. The draft status indicates this is only beginning the RFC process, so software developers may well take the view to wait till RFC approval before implementing it. The IETF website shows last submission date was July 2008 and the earlier versions of the draft go back to 2004. I guess no one other than filezilla supports this. The hacked MDTM is marginally wider spread as cited in my previous reply

[botg]

The hacked MDTM is marginally wider spread as cited in my previous reply

Yes, but in direct conflict with the MDTM RFC. In other words, broken and potentially dangerous.

[BrunoJ]

FYI - SyncBack has incorporated the MFMT command since my original post. Problem solved