Description of problem:
When ncftpput tries to use MDTM on a file with embeddedblanks in the name, the
MDTM command fails on the server.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a file with embedded blanks in the name
2. use ncftpput to transfer the file
The STOR command was successful, but the MDTM command failed
I expected the MDTM command to change the date/time stamp on the server.
A cut/paste from the transfer log:
Cmd: STOR $DOCUMENT CHANGES LOG.XLS
150: Opening BINARY mode data connection for $DOCUMENT CHANGES LOG.XLS.
226: Transfer complete.
Cmd: MDTM 20060801162748 $DOCUMENT CHANGES LOG.XLS
550: 20060801162748 $DOCUMENT CHANGES LOG.XLS: No such file or directory.
ncftp is in Fedora Extras, changing product
(In reply to comment #1)
> ncftp is in Fedora Extras, changing product
Sorry about that. :-( Frankly, I really do not pay much attention to where I
install a package from (Core vs Extras). But I DO appreciate the difference for
reporting bugs. First I tried finding out from "yum info ncftp", but that only
told me it was installed. :-) *
So, I selected "Core" when creating this bug report, and found ncftp in the
"component list", thus coming to the (incorrect) conclusion that ncftp was part
* I created a new bug (enhancement) report against yum to report the repo the
packae came from, if known (Core/Extras) Ref.
ncftp has just been updated to 3.2.0, can you try again with that latest version
and report if the problem still exists? If it does, I'll report it upstream, as
Mike Gleason is really responsive regarding issues in ncftp.
According to www.ncftp.com, version 3.2.0 was released 5 Aug.
I do not see that yet in "yum info"/"yum update".
When can I expect this new one to be available via "yum update"? I'll watch for
it andlet you know my re-test results.
Oh, sorry : The FC devel package is already available, but the FC4 and FC5 ones
were rebuilt after, and may not yet be available. They should be once the next
push takes place, which is usually a matter of a day or two at most.
No problem.... I'll watch for it in the next few days then, and let you know
what I find. :-)
ncftp was updated on my FC5 system to 3.2.0-1 and this problem is still there.
Please pass these details upstream, as per comment #3. How can I track it upstream?
Thanks for confirming. I've sent the bug report upstream.
Here is the detailed reply I got from Mike Gleason :
"Using MDTM to set a timestamp is not defined by the protocol, so
there is no official provision for specifying filenames when using it
in the non-standard way. Currently NcFTP does:
MDTM 20060801162748 $DOCUMENT CHANGES LOG.XLS
And the bug reporter apparently feels that it should do:
MDTM 20060801162748 "$DOCUMENT CHANGES LOG.XLS"
But this goes against standard convention for all other FTP
commands. For example, to query the timestamp, this command would
work on any RFC 959 compliant server for a file that had spaces in
MDTM $DOCUMENT CHANGES LOG.XLS
NcFTP guesses that the standard convention would apply to the
alternate MDTM semantics. Therefore, it is probably more accurate to
say that the FTP server software needs to be fixed, rather than NcFTP."
So it does seem as if the problem might be with the FTP server on the other end.
I'd tend to agree, seeing that you don't need to quote the file name for STOR
for instance. What FTP server are you using? Could you try with others, vsftpd
(the Fedora default) for instance to see if it works?
In the absense of an RFC describing an "official" method to alter a timestamp, I
agree this could be be a "server problem".
In this case, the far-end ftp server is wu-ftpd. ncftpput reports:
LibNcFTP 3.2.0 (August 5, 2006) compiled for linux-x86-glibc2.4
Uname: Linux|boris|2.6.17-1.2174_FC5|#1 Tue Aug 8 15:30:55 EDT 2006|i686
Glibc: 2.4 (development)
Remote server is running wu-ftpd.
220: vux22 FTP server (Version wu-2.6.2(1) Wed Jun 28 17:32:01 EDT 2006) ready.
This is the ftp server of NetworkSolutions.com, I do not have any control over
Mike referred to RFC 959, but I could not find any reference to MDTM in that
RFC. (ref. http://www.ietf.org/rfc/rfc959 )
It does make sense though, that if using quotes around the file name were the
answer, I'd expect more errors reported by the server in this case. As in, File
$DOCUMENT not found; File CHANGES not found; File LOG.XLS not found.
Googling for FTP MDTM came up with this reference, but it is almost 6 years
old... saying MDTM is "experimental" etc...
Perhaps ncftpput should not issue the MDTM command when MDTM is not returned in
the result of the FEAT command? Though the error is harmless enough and draws
attention to the fact the server file date/time was not modified.
From what I've found Googling, MDTM can only (officially) query the timestamp
for a file on the server. To modify the timestamp on the server, the MFMT
(Modify File Modification Time) command should be used. But, I can't find that
in an RFC either. I also don't know if wu-ftpd supports MFMT/MFCT.
There is an RFC draft (expired) that addresses this: Ref.
A search at http://ietf.org for "ftp mfmt" came up with this:
At least one server recently added support for these commands. (Ref.
Without a definitive RFC to cite from, I'll have to concede this is not a bug in
ncftpput.... just a nuisance that all servers do not follow the same convention
for this function.
Perhaps ncftpput SHOULD try MFMT if the "conventional" MDTM fails.... or use
MFMT first, then the "convention of MDTM to change the timestamp".
I'll see if the wu-ftpd server in question supports the MFMT command (not
hopeful), and in the absence of an RFC, I don't have a leg to stand on to open
an RFE against that server, nor ncftp fr that matter. :-)
Let's leave this open for a little while... I need some time to set up some
testing with some different servers.
From a comand line ftp session, connecting to NetworkSolutions ftp server, I
determined their server does not understand this MDTM convention used to modify
the modification time of a file.
HELP MDTM tells me the format is
MDTM <sp> <path>
I also confirmed their server does not have the MFMT nor MFCT commands...
So, I think my best bet willl be to do three things:
1 - see if I can get wu-ftpd to adopt the MFxx commands
2 - see if I can get NetworkSolutions to update their server when the new
wu-ftpd is released (they seem pretty current, probably not a real issue)
3 - see if ncftp will provide an option to use MFMT if MDTM fails....
I suspect this will lead to a chicken/egg scenario... wu-ftp won't want to make
the change because not enough clients use it; ncftp won't do it because not
enough servers support. Catch-22. :-) Without an RFC, it's difficult to make a
compelling argument either way. It works for some, but YMMV.
What do you think? Suggestions/comments?
OK.... after a fair amount of Googling (is that a verb now?) I finally tracked
down the author of the MFxx set of commands and the RFC Draft. I received a
reply from him this morning showing me where the (currently expired) draft is,
and some other good news.
FYI, I am about to submit draft #2 to the RFC Editor and will request that
that version be considered for publication as an RFC."
In this new light.... perhaps I could ask you to rephrase the orignal problem to
Mike Gleason, upstream.
Or, do you prefer this to be closed, and a new bugzilla report be created?
--- new report summary ---
ncftpput currently uses a non-standard extension of the MDMT ftp command to
modify the time stamp on the far-end server.
I ask that ncftpput be enhanced to use the MFMT command for this purpose,
falling back to the current practice when MFMT is not available on the server.
The MFMT command is described here, ( http://www.omz13.com/?page_id=9 ) and,
according to its author, Draft 2 is about to be submited to the ietf with a
request for publication as an RFC.
ncftpput MAY use the FEAT command to determine whether or not the MFMT command
is available.... however, I have experienced at least one server that does not
implement the FEAT command, but instead uses the HELP command to report back all
commands. Again, perhaps ncftpput could fall back to HELP when FEAT fails.
-- end summary ---
Thanks very much.
Sorry for leaving this bug untouched for so long, but... could you maybe discuss
these changes directly with the author (Mike Gleason), as he is the one who will
eventually accept and implement the change anyway? The problem isn't specific to
the Fedora package, nor is it really a bug per-se in the software itself.
I'm agreeable to closong this as "not a bug". The MDTM commands can be turned
off using a command line option (-o useMDTM=0)