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
of Core.

---
* I created a new bug (enhancement) report against yum to report the repo the
packae came from, if known (Core/Extras) Ref.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201066

Thanks,
Don Russell

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  
the pathname:

	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
their server.

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...
Ref.
http://www.landfield.com/wu-ftpd/mail-archive/wuftpd-questions/2001/Apr/0217.html

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.
http://www.indyproject.org/Sockets/Blogs/JPeterMugaas/draft-somers-ftp-mfxx-01.txt

A search at http://ietf.org for "ftp mfmt" came up with this:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=9161

At least one server recently added support for these commands. (Ref.
http://www.g6ftpserver.com/en/version )

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.

Thanks. :-)

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.

" http://www.omz13.com/?page_id=9

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.

No worries....
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)