Talk:File Transfer Protocol

From Wikipedia, the free encyclopedia

You have new messages (last change).
This article may be too technical for a general audience.
Please help improve this article by providing more context and better explanations of technical details to make it more accessible, without removing technical details. See below for more information.

Contents

[edit] Opening comments

Do we really need a cross-reference to Archie in 2003? --Vicki Rosenzweig

"It is hard to filter FTP traffic using a firewall, since the data connection is made to an apparently arbitary port". Is this really true? Is it not possible to just use passive FTP?

You can, but not everything can be switched into passive mode in an obvious way. It's really quite annoying. --Brion 16:42, 10 Aug 2003 (UTC)

[edit] Active and passive mode

I've put a description of active mode FTP. Will do passive mode later. - Ta bu shi da yu 00:37, 13 Oct 2004 (UTC)

  • I have removed this section (Mike Gleason). Sorry, but the section contained numerous errors. I also feel that these are internal protocol details that are of no concern to the reader (unless we want to write up an entire technical analysis of the protocol internals).
  • The errors are detailed below.
  • "Active mode requires both the client and the server to open a port and listen on it in order to establish an FTP session." Not true; the server does not need to listen on the port for the active data connection. It does need to be bound to port 20 for outgoing connections, but it is not listening on port 20 which would imply that someone is connecting to the server at port 20.
  • "Passive mode requires only the server to have a process listen on a port, and thus it bypasses firewall issues on the client computer." The reason passive mode is more firewall friendly is that for passive mode, the client connects to the server, rather than for active mode, where the server connects to the client on an arbitrary port. Firewalls are typically on the client side, and inbound connections on the client side are not desired. On the server side, there is already a port open for inbound FTP control connections, so it's not as problematic to open ports for inbound FTP data connections.
  • "A random unprivileged port (a port with a number above 1024...". The important thing to note here is that it doesn't have to be above 1024. By convention it is, because the early years of FTP were dominated by TCP/IP stacks from the UNIX operating system, where this restriction was imposed. The port number here can be any valid IP port number, from 1 to 65535, and it doesn't need to be "random." It would be better to say an arbitrary port number.
  • "...known as the command port..." It's more commonly known as the control connection port.
  • "The source port is now the random port number x on the client and the destination port is port 21 on the server." This section is supposed to contrast active (PORT) and passive (PASV) data connections, but you're discussing the setup of the control connection.
  • "The client starts listening to port (x+1) and sends a PORT command to the server..." The client can choose any port it wants for use with PORT. It does not have to be x + 1. You're probably confusing this with the fact that the data connection, by default if not specified by the client, is x - 1.
  • "The server opens port 21..." No, port 21 is already open and in use for the control connection. It connects outward to the client with source port 20.
  • "The client opens a connection to port 21 on the server via the client's data port and then sends the server an acknowledgment that it has established the connection." Connections are already open. An acknowledgment is made on the control connection. There is certainly no mixing of the data connection and the control connection.

[edit] Active mode Port on the Server

In the text it is mentioned that the port on the server is 21, this is the control port. The data port should be 20.

  1. client sends "port x"
  2. servers opens connection from "server:port 20" to "client:port x"
  • Not according to the RFC: "8. CONNECTION ESTABLISHMENT: The FTP control connection is established via TCP between the user process port U and the server process port L. This protocol is assigned the service port 21 (25 octal), that is L=21." [1] - Ta bu shi da yu 11:04, 27 Oct 2004 (UTC)
  • No, whoever wrote the original note was correct. The server listens on port 21 for the FTP control connection, but active data connections (PORT) originate from the server from port 20 and connect out to the client. --Mike Gleason

[edit] So why FTP?

Reading this article, I had one goal in mind: to figure out what advantages FTP has over HTTP. I didn't see any. Perhaps these could be added? —Simetrical (talk) 02:17, 21 Mar 2005 (UTC)

  • HTTP when transferring binary content, encodes it in base 64, which basically increases the volume of the transfer by a huge amount. FTP on the other hand, uses binary transfer (no encoding is done), which means the transfer is faster.
  • FTP requires the the user to login (anonymous ftp is also common these days) before he can fetch content. so authentication is built into the system.
  • FTP uses seperate connections for control (user commands) and data transfer. The data transfer occurs on arbitrary ports, which makes it harder for FTP connection to get through strict firewalls.
  • HTTP is a stateless protocol. This means the client has to maintain its own state. FTP on the other hand, maintains the state for the user, e.g. his current directory.

Saish 12:31, 29 October 2005 (UTC)

There is no requirement to encode binary content transferred over HTTP. The standard has provisions for this, but they are fortunately hardly ever used or needed. The only required overhead comes from the textual HTTP header, which is negligible when transferring large files. Aapo Laitinen 16:22, 29 October 2005 (UTC)

Indeed HTTP can require the user to login, too. And since HTTP 1.1, it shouldn't be stateless anymore. But it's true that there's nothing in HTTP about manipulating files and directories in the remote server. HTTP is just for retrieving files (well, not in its origins -PUT, etc.- but in the practice it is).

Of course, it's completely possible (and some web hosting sites have done it) to build an FTP-equivalent system (using CGI) which uses http to transfer files to and from the client machine. Those systems have the advantage of being more familiar for non-expert users (well, few people know there exist ftp clients... apart from their browser). Another advantage is that what would be the client program is web-based, and thus designed by the server (this could be thougth as a disadvantage, but there certainly must be ways for automatically doing it if you don't want to handcraft a client).

An important thing to consider is that FTP predates HTTP. It's not like somebody thougth it would be better than HTTP =D. (As trivia, Tim based HTTP's response codes -as 404- on FTP's).

-- Euyyn User:Euyyn, 26-Nov-05

[edit] Requested move

File Transfer Protocol → FTP – (1) The term file transfer protocol, when uncapitalized, is a generic term which can refer to any method of transferring files from one communications point to another. (2) I have just written a new article on file transfer protocols in general and don't want it to be confused with this one. (3) The Internet File Transfer Protocol discussed is better-known as FTP. (4) The titles of most of the other protocols in the Internet protocol suite (HTTP, etc.) use the acronym rather than the full name. —Psychonaut 14:40, 2 Apr 2005 (UTC)

Add *Support or *Oppose followed by an optional one sentence explanation and sign your vote with ~~~~
  • support so it matched HTTP, etc. Thryduulf 16:41, 2 Apr 2005 (UTC)
  • Oppose --R. S. Shaw 20:59, 2 Apr 2005 (UTC)
  • Support We talk about "FTP sites" all the time, but never "File Transfer Protocol sites". —Michael Z. 2005-04-4 08:06 Z
  • Oppose. Please see Talk:Post Office Protocol for a simular requested move. The outcome of that discussion was that the article should not be under the TLA (three letter acronym). It's more clear, more encyclopedic, and more consistant with other articles to spell out the name in the title. Jonathunder 08:18, 2005 Apr 4 (UTC)
  • Oppose -- I suggest that Psychonaut moves his/her article to protocols for file transfer or some other name, then there would be no problem. -- Philip Baird Shearer 14:35, 6 Apr 2005 (UTC)
  • Oppose. violet/riga (t) 22:49, 6 Apr 2005 (UTC)

Voting closed

[edit] Discussion

Add any additional comments

I propose moving this page from File Transfer Protocol to FTP for the following reasons:

  1. The term file transfer protocol, when uncapitalized, is a generic term which can refer to any method of transferring files from one communications point to another
  2. I have just written a new article on file transfer protocols in general and don't want it to be confused with this one.
  3. The Internet File Transfer Protocol discussed is better-known as FTP.
  4. The titles of most of the other protocols in the Internet protocol suite (HTTP, etc.) use the acronym rather than the full name.

—Psychonaut 14:37, 2 Apr 2005 (UTC)

  • Reason 4. above appears wrong, or at least misleading. Very few of the other protocols which appear in the Internet protocol suite box in fact have their articles titled with the acronym rather than the full name. I checked these out explicitly:
    • SMTP -> Simple Mail Transfer Protocol
    • SNMP -> Simple Network Management Protocol
    • TCP = disambiguation page -> Transmission Control Protocol, plus non-IP stuff
    • UDP = disambiguation page -> User Datagram Protocol, plus non-IP stuff
    • HyperText Transfer Protocol -> HTTP
    Only the last is as stated in reason 4. Judging by the links in the suite box, there are only 3 of the 20 articles that use the acronym. (The other two are IPv4 and IPv6, and note that their parent article is Internet Protocol, not "IP".)
    Hence, I vote no rename for File Transfer Protocol.
    I suggest that instead the new File transfer protocol article be renamed (moved), to reduce confusion. There are probably many alternatives, such as file transfer methods, file transfer standards, List of file transfer protocols, etc. --R. S. Shaw 20:59, 2 Apr 2005 (UTC)
  • It is true that one says an "FTP site" but if one is programming to the protocol one says "File Transfer Protocol" one does not say "what is error number 550 in the FT Protocol" (it makes it sound like something in the Financial Times), one says "What is error number 550 in the File Transfer Protocol?"
  • To talk about a "file transfer protocol" as a generic term, is using a very narrow definition of inter-computer comminications is all about. For example what about the old CPM "Periphal Interchange Program" or Kermit or rsh, or ssh, all of which can transfer finite and infinite data sets, but are not "file transfer protocols" unless one defines all data trasfered as files. -- Philip Baird Shearer 14:35, 6 Apr 2005 (UTC)

[edit] Decision

It was requested that this article be renamed but there was no consensus for it be moved. violet/riga (t) 22:49, 6 Apr 2005 (UTC)

[edit] Protocol in more detail

I don't think it would hurt the article to add a summary which discusses the working protocol in more detail, including establishing a connection, sending data, and terminating a connection. Maybe something about a the various FTP commands that are part of the protocol (file system browsing, etc.). It wouldn't have to be especially technical, but just discuss the parts of a typical FTP conversation, and some of the things that the client can "tell" the server. Brent 14:10, 23 October 2005 (UTC)

Maybe add something about the different directory listings with unix style the most common, vms and dos.
Could be helpful to developers.
--Flippy 15:57, 28 May 2006 (UTC)

[edit] Understanding FTP

I know wikipedia isn't a how-to-do but I normally find there is enough info in a wikipedia article of this type to be able to start to figure out how to be able to do something. When I came to this article a few weeks it was much less helpful than similar articles have been (and with the notice already in place). What I didn't grasp at the time was that you need an FTP client in order to be able to download and upload files (I already had access to a server but didn't know how to access it and clearly couldn't do anything with the relevant interent page, and I still feel that this how it works could be explained more clearly in the opening, what we have now explains it much better than before but maybe not as well as could be done. Good to know there are some free FTP clients out there, SqueakBox 17:04, 9 December 2005 (UTC)

I added a how-to section. Try it out. I've been using FTP for a while so if I went to fast in my explanation please revise it so its easy for a beginner to follow. JesseHogan 17:52, 10 December 2005 (UTC)

[edit] Expert Tag

Do we still need the banner saying this article needs an expert. I'd like to remove it.JesseHogan 01:16, 14 December 2005 (UTC)

Removed JesseHogan 14:34, 19 December 2005 (UTC)

[edit] Proposal to merge FTP over SSH into this article

I think that the content currently in the FTP over SSH article would be better served by being included in this File Transfer Protocol article, as part of a general discussion of "securing" FTP, including other approaches such as FTP over SSL/TLS. -- JTN 14:41, 28 December 2005 (UTC)

  • Agree - good idea, FTP Over SSH is just another way of securing the protocol so it should be listed here. Martin Hinks 17:29, 29 January 2006 (UTC)
  • By all means, go for it! - CorbinSimpson 17:54, 29 January 2006 (UTC)
  • I do not agreee. This belongs in a 'things you can do with SSH' page and not a 'good ways of doing FTP page'. If people want to do FTP over SSH, then they should define an AUTH mechanism to extend RFC2228 and not just stick the control connection in a secure tunnel. Paulfh 16:56, 30 January 2006 (UTC)
Surely this is not a discussion on whether you think FTP over SSH is a "good way of doing FTP" but merely whether it should be merged into this article as it relates to FTP. Martin Hinks 21:15, 30 January 2006 (UTC)
As long as it is merged alongside a disclaimer stating that it is a bad thing to do - I have no problem. But putting a list of good things and bad things on the same pseudo-authoritative source without editorial comment leaves readers with little understanding as to why the information is present Paulfh 11:17, 2 February 2006 (UTC)
We cannot put a disclaimer saying what are bad things to do as it would violate Neutral Point of View policies, but we can state the advantages and disadvantages of the approach and let the reader make up their own mind. As long as each method specified gives both the positives and negatives I think the reader will be able to make an informed decision. Martin Hinks 11:29, 2 February 2006 (UTC)
  • Merge. The FTP over SSH article already states the problems of the method. Kwi | Talk 18:00, 2 February 2006 (UTC)
  • No Merge: It is rather an explanation what you can do with SSH not an extension or feature to FTP. As the article name states: Over SSH you can also do FTP. Dequid 01:26, 10 February 2006 (UTC)
  • No Merge: Just as FTP uses the TCP/IP layer, SSH can use the FTP layer. This merge would be as legitimate as merging FTP with TCP/IP.
  • Comment. An anon went ahead and copy-pasted the text into this article anyway last week. I don't see consensus here that is clear in either direction. FYI. — Saxifrage ✎ 18:56, 2 March 2006 (UTC)

And while you're at it... How about the article for FTPS? That should be merged into this one as well.12.110.196.19 18:42, 3 April 2006 (UTC)

Guys, don't bother. SSH has been circumvented. Use SSL instead.

/me waits for someone to post something about SSL not being compatible with the FTP protocol. CMON GUYS! BRING IT ON!

--Insanitor.

Don't disturb Wikipedia to make a point. If you have something to contribute, feel free. Mocking the process will just get you on the wrong end of some of our processes. Incidentally, you can sign your comments by typing four tildes (~~~~) where you want your signature to appear.
I use SFTP myself. — Saxifrage ✎ 05:21, 7 July 2006 (UTC)

The process has mocked me including you and you know it.

I am already on the wrong end of your process so give me a break ok?

This process has got me sick already and don't tell me that I have no right to feel the way I do about it.

So spare me your process, thanks.

207.38.191.195 01:38, 9 July 2006 (UTC)Insanitor.

I haven't mocked you. You're taking this entirely too personally. If the process doesn't go the way you want, that would be because you want something that isn't suitable for Wikipedia. Accept that and move on, or switch to wanting to do something that is acceptable by Wikipedia's standards. Wikipedia isn't made the way it is just to mock you.
If you're feeling too sick to edit like a mature adult, your best course of action would be to not edit until you can. — Saxifrage ✎ 01:43, 9 July 2006 (UTC)

I thought that wikipedia was an encyclopedia that could be edited by anyone.

Then I find out that you remove the link to my tutorial on purpose and now you say that I need to edit like an adult?

You invent this process to hinder my efforts and now I am not supposed to take this personally?

What planet do you come from?

On Earth we have consideration for other people's feelings.

Why did you put my ip address on the last message?

Do you want to hack into my computer?

--Insanitor.

If you check the edit history, you'll see that you put your IP address on your last post because you weren't logged in.
I didn't invent any of this process, I'm only trying (in vain it seems) to educate you about it. Anyone can edit Wikipedia, but that doesn't mean what people decide to put on it is sacred and must never be deleted. There's a lot that's of no use to Wikipedia. And yes, editors are expected to behave themselves. That's why we have lots of policies about being civil and not behaving badly, as well as banning policies for people who refuse to follow them. — Saxifrage ✎ 03:16, 9 July 2006 (UTC)

Sir I call into question your honesty and integrity concerning this.

I was logged in just fine.

My IP address did not show up until you suggested that I put "four tildes" to sign my name with.

And then all of a sudden my IP address shows up.

If you think you are trying in vain to educate me about the process then the failure is yours and not mine.

According to what you have told me in the past editors are supposed to have a consensus on whether or not the link is included and the final decision is supposed to be based on consensus.

http://en.wikipedia.org/w/index.php?title=User_talk:Insanitor&oldid=49881266

If you read this discussion carefully the consensus so far was that there is no reason why my link should not be included yet I expect your edit if I dare to put the link back into this article.

Every editor including yourself have initially admitted that the link cannot hurt.

The fact that you and another editor have changed your minds, does not negate the fact that initial consensus nevertheless is still consensus.

It would seem to me that this process as you call it is not a process at all but actually a non standardized form of arbitrary exclusion by so called "editors" who do whatever they want and interpret the process according to which way the wind blows.

All editors including yourself initially indicated that the link being there cannot hurt the article.

You sir are not what you claim to be.

I might not have my link included in this article but I retain my dignity and perseverance in pointing out the facts in this discussion and arguing my points using factual evidence and anyone reading this using common sense and taking into account factual evidence will undoubtedly agree with my conclusions.

I sincerely hope that one day someone reading this discussion will look at my tutorial and get an ftp site running and thank me for my efforts because it seems that in here appreciation for effort is in extremely short supply.

I sincerely hope that anyone reading this will avoid the waste of time and energy I did and will see this editing process for what it really is.

--Insanitor.

I hereby retract my initial request to include my link in this article.

I am tired of being unfairly treated and if at any point wikipedia decides to include the link to my tutorial in the FTP article as I initially requested (not the link to it in this talk page) then the owners of wikipedia will hear from my lawyers.

A copy of this discussion and all related documents will be sent to the owners of this website.

--Insanitor.

  1. There's no such thing as "initial consensus". Consensus is what comes out of the end of discussion. I would not remove a link if that's what others thought was appropriate.
  2. You weren't logged in when you made that edit. See, here is the record of your edit. The four tildes signs your username, and if you're not logged in, your username is your IP address. IP addresses are publicly visible on the internet, and Wikipedia hides them as a courtesy for editors who log in. That's part of the purpose of having an account. I am signing this with four tildes, and it shows my username because I know well enough to be logged in when I do.
  3. I never said that the link couldn't hurt, only that you should not be the one to decide since you have a vested interest. What others decide I'd abide by, and I haven't really contributed to the discussion until recently.
  4. I never claimed to be anything.
  5. Don't make legal threats. There isn't a court in the world that would support a civil suit for linking to a site against the owner's wish. Not that your sour grapes will be relevant, since I doubt the decision will be to offer a link anyway.
  6. Since you seem to have no interest in actually helping the encyclopedia beyond getting your page linked, your disillusionment is no loss to the project. Cheers, and goodbye! — Saxifrage ✎ 09:17, 9 July 2006 (UTC)

I read the rules.

There was consensus.

You simply failed to include the link.

You claimed that you would allow the link if there was consensus and there was.

You ignored it.

Here are my the tildes.

Insanitor 23:38, 9 July 2006 (UTC) --Insanitor.

You're quite right that I ignored it. As I promised you, I would allow the regular editors of this article to debate its merits and include or disinclude it. They debated the merits and decided it couldn't hurt, but obviously didn't care enough to actually add it. My "allowing" was to stand out of the way. — Saxifrage ✎ 05:46, 10 July 2006 (UTC)
This is getting quite far away from the subject of FTP. If you want to talk to me specifically, you are welcome to come to my Talk page. Otherwise, I will refrain from responding any more here to discussion that is unrelated to improving the article. — Saxifrage ✎ 05:49, 10 July 2006 (UTC)

[edit] Image of an FTP session?

Why is Image:AnonFTPSession.jpg necessary for this article? More specifically: why is a 108 KiB file of pure text required when it's transcription is easily sufficient? Cburnett 21:42, 23 February 2006 (UTC)

Nevermind, I guess. I already substituted the image for equitable text and put the image up for IFD. Cburnett 21:52, 23 February 2006 (UTC)
Now the text doesn't match the example given. ncftp is used instead for the DOS ftp client. The output doesn't even have the response codes now. The section was intended to give inexperienced users basic information on how to connect to an FTP server. Normally I would never print a picture when text would be adequate but most users have never used a command line interface and I wanted to make it perfectly clear how their session should look. I prefere we restore the picture but we should at least make the output match the example. JesseHogan 23:53, 23 February 2006 (UTC)
Wikipedia is not an instruction manual nor a tutorial. This is clearly your intention. Cburnett 02:38, 24 February 2006 (UTC)

To make you happy, though, I did transcribe the image. I still will absolutely insist that a 108 KiB image is completely and totally 100% irrelevant. Cburnett 02:50, 24 February 2006 (UTC)

Fair enough. Thanks. JesseHogan 17:11, 25 February 2006 (UTC)

[edit] Not a tutorial

I propose removal and or rewriting of the "How to connect to FTP" section. Wikipedia is not a tutorial. Besides, the example given is platform specific and practically obsolete. Tutorials like this should be moved to the relevant FTP Client page if included at all, and not on this page, the purpose of which is to document the Protocol, not specific programs that utilise it. Comments? Martin Hinks 10:15, 26 February 2006 (UTC)

Agreed. Perhaps it should be moved to Wikibooks instead? That's where "howto" material from Wikipedia is often moved. — Saxifrage ✎ 18:38, 3 March 2006 (UTC)

[edit] Debate on inclusion of external link

Want a tutorial? YOU GOT IT!

Hi guys. I am Insanitor, I am the author of several classic tutorials on how to get an FTP server running on the internet. Looking at the links on the FTP page probably makes the beginner cringe in fear, but there is no cause for worry. My tutorial will fix all of that. My tutorial comes with a dictionary that explains all of that technical jargon in PLAIN ENGLISH. It comes with screenshots so you'll never be confused about anything. Whether you want to run your FTP server behind a hardware firewall, a router, whatever, my tutorial will teach you how. My latest tutorial is a combination of all the three tutorials I have written so far with added features. It is an interactive tutorial, sort of like a wizard where you could choose which parts of each tutorial you want to read. It is organized in much the same way as wikipedia, because every word that you might not know the meaning of will come with a link directly to the dictionary, so you can understand what that word means. Each part of the tutorial is divided into several numbered sections and the information is organized in between all three previous tutorials. My new tutorial supports Serv-U, Gene6, and Bulletproof FTP Server in an interactive interface with a tree structure. Creating new users, installation and permissions settings for upload, anonymous, and download accouts are supported. Want to diagnose a problem? I've got it covered. Want to know if you have made a common mistake? Look them up! It is on insanitor.com along with a watermark for each screenshot. I put it on insanitor.com so that everyone here can access it. My normal website address prohibits access to certain people. By putting it on insanitor.com, it is accessible to everyone. My host, is willing to spare his bandwidth and has been informed of the new tutorial's content.

And now... Here is the Insanitor FTP Tutorial Wizard, the tutorial you all have been waiting for!

Ready! Set! Go!

http://www.insanitor.com/introduction.htm

—The preceding unsigned comment was added by Insanitor (talk • contribs).

I've replaced this here after it was reverted as spam. Actually, Insanitor placed the link into the article and I removed it as it's their own site. I told them that the correct way to get a link to a site you control into an article is to make a case for its inclusion on the Talk page and allow other, non-partisan editors to decide for or against the link. (See Wikipedia:External links for this guideline.) The fact that they are following this rule and not simply re-inserting the link into the article is a very good sign of willingness to Do The Right Thing. I ask everyone to assume good faith in Insanitor's good intentions and willingness to work within our rules and consider this honestly (and avoid biting newbies). After all, the link being here for the duration of the discussion can't hurt anything, and it might benefit the article. I turn it over to the other editors watching this page (since I will recuse myself due to my part in all this): Does the article benefit from this link? Should it be included or left out? — Saxifrage ✎ 10:16, 4 March 2006 (UTC)
Here's my evaluation of the site:
  • First thing, WP is not a tutorial so should links to tutorials be included? I don't see why not.
  • Secondly, is the link informative? If you don't know a thing about FTP or administrating any FTP servers, then sure.
  • Thirdly, it's ad free and popup free.
  • Fourthly, I find the site unprofessional for many reason. In particular, I can tell by the terminology used that insanitor is a novice to FTP and the IP suite (e.g., "inside IP" and "outside IP"). None of the images have alt tags for the vision impaired. Many pages violate W3C HTML standards (some pages don't even have a BODY tag).
All that said, I see little reason to not include it. That is until a better tutorial comes along (the fourth point is mainly here to gives grounds to replace and define a "better tutorial"). Cburnett 16:07, 4 March 2006 (UTC)
I see no reason not to include a link to a how-to. Quite honestly, to all of you who say Wikipedia is not a how-to; fine, yes, you're right. However, think about your users here: they come because they want to learn something, I am willing to bet that if you poll the next 100 people who type "ftp" into Google, you're going to find a large percentage are interested in how to use the damn thing (its not precisely intuitive, to be honest, not hard either). So, fine, we may not provide a how-to, but lets at least help them get where they want to go. That said, here is another ftp tutorial that might fulfill the need (http://www.freewebmasterhelp.com/tutorials/ftp). It doesn't tout any one particular client, a problem with most ftp tutorials I read (a case of "here's how to use acmeftp", not "here's how to use ftp"). Cheers. SavantEdge 12:49, 5 May 2006 (UTC)
A link to a howto/tutorial is fine in my books, after all it may prove useful to many users who visit this page. My main concern at the time of writing my above comment was that the majority of the article on the File Transfer Protocol was a tutorial that was specific to an operating system and client instead of giving encyclopedic information on the protocol. I agree entirely with Cburnett's evaluation of the site (especially the lack of professionalism) with one further point to add; it does not give an in-depth account for clients, only server setup. If I find a better tut, I'll report back, otherwise it seems fine to add it to the links section. Martin Hinks 15:20, 5 May 2006 (UTC)
I agree with you; the article should be more about the protocol itself than about how to use it. Perhaps, just at the very beginning, a short note saying, "If you are looking for information on how to use FTP, please check out one of the tutorials listed at the bottom of this page."; and then we put a few not-client-specific tutorials at the bottom there. SavantEdge 12:50, 30 June 2006 (UTC)

I really don't see how what you guys said is relevant...?

First of all the site loads and works perfectly in Internet Explorer and Mozilla Firefox so making it w3c html compliant is not really necessary is it?.

Second, I am running three different websites that are Valid HTML 4.01 Transitional compliant so it's not as if I am not capable of making the tutorial w3c compliant. If you want the addresses for those sites then they are available upon request but that's not relevant either is it?

Third, I used the terms "inside IP" and "outside IP" because I wanted to explain what these terms mean to beginners. It was not my intention to write a technical manual on the FTP protocol itself.

I also resent the comment that I am a "novice to FTP". I have helped hundreds of people get their FTP servers running by posting my tutorial.

I only agree with your statement that my tutorial does not include alt tags for the vision impaired, but that is because I did not write the tutorial for the vision impaired.

It seems to me that you have misinterpreted my purpose for writing this tutorial.

Basically, I wrote a tutorial on how to setup an FTP server under windows for beginners with screenshots.

Nothing more and nothing less.

Gee, I don't know... Should I include my mother's recipe for Veal Parmigiana in my tutorial?

Would that increase the chances that a link for my tutorial will be included in this article...?

Now I am totally confused. Please give me some Tylenol or hit me over the head with a hammer...

--Insanitor

P.S.

Let's examine the links that are included on this article to see if they are w3c html compliant.

This one isn't.

http://www.ftpplanet.com/ftpresources/basics.htm

Failed validation

Sorry, I am unable to validate this document because on line 259 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.

How about this one:

http://www.ncftp.com/libncftp/doc/ftp_overview.html

Failed validation, 9 errors

Maybe this one?

http://slacksite.com/other/ftp.html

Failed validation, 47 errors

How about this one:

http://dmoz.org/Computers/Internet/Protocols/FTP/

Wow! This one is ok. Two out of 3 so far is not bad, right?

This one:

http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html

Failed validation, 8 errors

Here's the last one:

http://www.bitkinex.com/ftpfiletransfer.php

Failed validation, 1 error

Awww... One error short of valid HTML!

You guys are toying around with me and I want to know why!


I agree that a link's inclusion should not be based on W3C validation - google.com fails the W3C auto-checker! However, that is not really the issue and since my last comment on this topic I have somewhat changed my mind. This article is about the File Transfer Protocol - that is; an explanation of the uses of RFC 0959 and an article that describes the technical details of that RFC. FTP is not restricted to a single operating system, client or server application, it is the underlying mechanism through which files may be transferred. A more appropriate place for a tutorial that details the setup of a specific server for a specific operating system would be under the Wikipedia article for the specific software. If a rationale can be provided that shows clearly how the tutorial link enhances the article on RFC 0959 and it's extensions then it can be included, otherwise it must go elsewhere under a topic to which it is better suited (try Serv-U). Martin Hinks 08:22, 6 July 2006 (UTC)

If someone is looking to use FTP, they will most likely be running a Windows OS.

If someone is looking to run an FTP server they will probably use one of the three most popular FTP servers which are those three I support in my tutorial.

If someone wants this information and uses Wikipedia to get it then if we remove the tutorials link on this article then Wikipedia is pretty useless.

I agree more with what SavantEdge had to say about this.

P.S. The Serv-U article has almost no information, and also, Serv-U has their own tutorial so posting my own tutorial on that article would be a useless waste of time. The other FTP servers in my tutorial have no articles at all on wikipedia.

If information is not posted in this article then such information will never be found on wikipedia. Assuming that the mission of this website is to inform, then not including tutorial links on this article will abandon that mission.

Perhaps I should stop wasting my time here as well.

--Insanitor.

The aim of Wikipedia is to create an encyclopaedia, not to provide training manuals/tutorials, a simple search for ftp tutorial will do that job. This is not any form of attack on your efforts to create an FTP Server tutorial, which it would seem you have done succesfully, but I am instead calling into debate it's relevany for this article which is not about how to run your own FTP server but instead about the specifications and standards of the underlying protocol. I would also call into question your assumption that the majority of people who wish to use FTP are Windows users, with Apache holding the largest market share of web servers[2], it is probable that many first time unix/linux system administrators would want information on FTP. Furthermore, if someone *expects* Wikipedia to point them straight to a tutorial on how to configure their exact server (OS, Server specifics etc.) then they have missed the point of Wikipedia. Finally, I also must refer you to WP:NOT which represents official Wikipedia policy and present this extract:
"while Wikipedia has descriptions of people, places, and things, Wikipedia articles should not include instruction - advice ( legal, medical, or otherwise), suggestions, or contain "how-to"s. This includes tutorials, walk-throughs, instruction manuals, video game guides, and recipes."
If you still feel that, in spite of official policy on Wikipedia stating otherwise, the link should be included, then this discussion would best be furthered on the WP:NOT talk page where you would have to convince all involved that a change to official policy is needed. Martin Hinks 13:05, 6 July 2006 (UTC)

I see your point and I appreciate your being diplomatic about this.

My point is this:

All of the knowledge in the world about the FTP protocol itself will NOT help you run an FTP server nor will it help you use an FTP client nor will it help you utilize FTP to share and/or download files from an FTP.

If I wrote an article about different types of filaments used in light bulbs and light bulb construction techniques, that won't help you turn the light bulb on. To do that, you need electricity and you need a switch.

A manual filled with nothing but with technical jargon is usually of absolutely no use to most people.

With people getting in trouble using p2p programs, people are looking for safer and more secure ways to share files and FTP is definately the way to go. People are now downloading and sharing things and they don't even know what they are sharing or downloading.

If someone looks for that information on wikipedia and only finds technical jargon about the FTP protocol, then that person will definately look elsewhere.

This article definately needs links for USEFUL information. There is no doubt about it.

I see nothing wrong with a section entitled, "If you want to use an FTP client or run an FTP server, then these links might help"

--Insanitor.

Keep in mind that Wikipedia is not a Google replacement. Information that will rapidly get out of date isn't of much interest to the encyclopedia in most cases, and how to use particular clients and servers is that kind of information. The technical jargon of the FTP protocol is exactly the sort of information that doesn't go out of date that Wikipedia is about collecting. For everything else, there is Google. — Saxifrage ✎ 01:46, 7 July 2006 (UTC)

Well, I can't argue with that. WWW.wikipedia.com will never reach google's level and it will NEVER ever be up to date and instead will provide obsolete or useless information that nobody will use.

--Insanitor.

AND! My Encyclopedia Americana has updates in additional books by year. So wikipedia won't be like my encyclopedia either? =D

Oh! May I ask how does someone get to be a famous editor like you? And like that other guy and like that other person here? I like obsolete information that I will never have to update. Where do I post that information? How How How???!!!!

I hereby retract my initial request to include my link in this article.

I am tired of being unfairly treated and if at any point wikipedia decides to include the link to my tutorial in the FTP article as I initially requested (not the link to it in this talk page) then the owners of wikipedia will hear from my lawyers.

A copy of this discussion and all related documents will be sent to the owners of this website.

[edit] RFC number/title

Can someone please clarify the references used to justify ongoing, slow simmering edit war over the disputed presence of a "0" in the title of the RFC? The title of the document linked to in the article (at IETF.org) has the title as just 959. The link itself works with or without the 0 and the title of the HTML page changes accordingly but the title of the document itself does not. The RFC as listed on faqs.org also does not have a preceding 0. So why is this the subject of contention? What evidence exists asserting that the title of the RFC has a leading zero? --ElKevbo 19:43, 24 July 2006 (UTC)

I was operating under the (apparently) mistaken belief that the zero was part of the official naming scheme. Your observations about the irregularity of the titling put this in doubt so I went and checked, only to discover that the link in the article is broken and only works now if the 0 is removed! Most drive-by editors seem to prefer the zero-less title and there's no justification for retaining it based on the IETF's own site, so I was wrong and it oughtn't be with the zero. — Saxifrage ✎ 03:04, 25 July 2006 (UTC)
I applaud your honesty and appreciate your swift reply. Good show! (But the link with 0 still works for me...?) --ElKevbo 03:11, 25 July 2006 (UTC)
That's very strange. With the 0 I get a IETF error page that says it can't find file "rfc0959.txt", and removing the 0 brings up a normal page with the text of the RFC. — Saxifrage ✎ 07:50, 25 July 2006 (UTC)
Never mind, it seems like that was a temporary glitch that they just happened to be suffering from when I did the check. Still, given their irregularity the zero seems to not be significant, so it's six of one, half a dozen of the other. — Saxifrage ✎ 07:53, 25 July 2006 (UTC)

[edit] FTP command articles

I have begun making articles for all the FTP commands starting with PWD (FTP command). Is this a bad idea?--I hate to register 16:17, 7 August 2006 (UTC)

Probably if all there is to say about each command is a one-line explanation of their function. Command listings are available all over the 'net and do a better job of it. — Saxifrage ✎ 17:36, 7 August 2006 (UTC)
Ok! Maybe something like this then?--I hate to register 09:24, 8 August 2006 (UTC)
I see you've made List of FTP commands. That looks a bit more like it, yes. — Saxifrage ✎ 16:52, 8 August 2006 (UTC)

[edit] client progs?

Links to popular FTP clients?

BTW, whats the name of that FPT client where you must do all the typing yourself?

-Unreg user

I believe it's called ftp, or maybe ftp.exe on DOS/Win.
A "popular" list wouldn't really do much good: everyone and their dog would add their personal "popular ftp client" and the list would be useless. See List of FTP clients and decide for yourself on one. — Saxifrage ✎ 21:21, 28 August 2006 (UTC)

[edit] Nonsense

This article is full of nonsense. A "8-bit protocol"? What's that? And what does UUencode have to do with FTP? Hard to filter FTP traffic? It's rather hard not to filter it, no? I propose this article be deleted, apart from the information that FTP stands for file transfer protocol it doesn't contain any facts. Only falsehoods and nonsense.

Please sign your comments using four tildes. I agree with you that there is some rubbish on this page, but there is also some good stuff that should be kept. Martin Hinks 17:26, 29 January 2006 (UTC)
Certain sections are too technicqal and do not add any value besides being yet another reference. For example, FTP return codes and FTP over SSH. I do not find majority of the rest of the article as junk. --Raanoo 09:39, 30 August 2006 (UTC)

[edit] Question

I'm a student and am pushing to get my school to support a FTP server or -like option/tool. What I'm mainly looking for is for students to upload unfinished projects and papers onto something so that they may log on again back at their house, work on it, and prehaps re-upload it if neccessary. My question is simply if a FTP server is my best option or if there's something better. If the FTP happens to be my best choice, I'm looking to find a good client and server. My school, I believe, has its own server -- all I need is probably the program. If there's something better than a FTP, then please tell me. By better, I mean in security and effiency. Thanks. Wolfie001 18:18, 8 September 2006 (UTC)

Better would be setting up an SSH server on the school's hardware. It's an encrypted link that won't send passwords as plaintext, and it gives you SFTP (Secure FTP) as well as the SSH shell server. Of course, it will be necessary for students to have individual accounts and to install a client that can connect to SFTP. If students don't already have accounts on the server or if it's impractical for the school to set students up with accounts, I'm afraid the project is doomed both for lack of software that will do what you want, and for security issues (i.e., students messing with other students' work). — Saxifrage ✎ 21:20, 8 September 2006 (UTC)
One more suggestion: you can use the online 'folder' space provided by the likes of Gmail, Yahoo. There are some Web sites that provide virtual briefcases. These could be accessed from both the school or remotely from anywhere there is Web access. About SSH client: students can consider using PuTTY--it's open source. I trust once a PuTTY session is established, all communication that passes through is encrypted. I imagine students using freely available command-line FTP client (ftp.exe on Windows and ftp on *nix). —Raanoo 09:00, 9 September 2006 (UTC)
Wait an minute though. Trustable web services such as Angelfire and Lycos use a FTP. That's where I got the idea since I'm a webmaster on Angelfire. I believe such FTPs are safe enough for what I want. We're talking about middle school level here. Angelfire requires a password before you connect with their FTP. I think that's enough safety for me. Students already have accounts on the server, but cannot access anything without being on one of the school's computers. And again, if Google and Yahoo! offers such tools, would it be so hard to set one up? Even if FTPs or SFTPs are not safe or efficient enough, could you suggest a program or applet thatt allows what I'm trying to do that can be run on the school's server?
I resist to answer here as this discussions is supposed to be about the article itself and not setup issues individuals face. Newsgroups could be best place for that. Good luck! — Raanoo 04:17, 11 September 2006 (UTC)
Could you at least reply in my user talk? Wolfie001 22:16, 11 September 2006 (UTC)

[edit] More accessible introduction

Oh, great. You need to make the article more understandable to a non-technical reader. That's exactly what I know how to do.

This article needs more context around or a better explanation of technical details to make it more accessible to general readers and technical readers outside the specialty,

I was trying to figure out FTP, so I went first to Wikipedia. I couldn't figure the article out. So I asked on one of my email list, and a professional editor explained it to me.

Then I went back to Wikipedia and said, "Now I understand what they're talking about!" This is a good job. Now I can get answers to all my further questions.

I'll try to re-write the introduction, with the editor's explanation, to make it clearer to an ignorant reader (like me).

I want to contribute, but I don't have enough technical expertise — so I'll contribute my ignorance. Nbauman 17:19, 30 October 2006 (UTC)

ElKevbo (Talk | contribs) deleted my change and said
(I don't think that's true but it's definitely not sourced.)
The benefit of sending files by FTP, over sending files as email attachments, is that FTP is a direct connection. Email travels through ever-changing relay points. FTP is thus more certain, easier to track and troubleshoot, more secure and quicker.
OK. The main reason I've heard techies recommend FTP to non-techies is that they say it's a better way to transmit files than email attachments. That's why I put it in the introduction -- you want the non-techie reader to know right away why this is useful.
Why is FTP better than email attachments for transmitting files? What's the citation? Nbauman 21:54, 30 October 2006 (UTC)
We can make the article more understandable to "non-techies" (and it definitely needs help in that area) while remaining accurate and precise. Characterizing FTP as "better" than e-mail for transmitting files is difficult (and inherently POV) without appropriate sources and citations. The particular explanation offered is incorrect. Specifically, FTP and e-mail traffic all "travel through ever-changing relay points" as they're both TCP/IP packets travelling over the Internet (ignoring the possibility of dedicated routes, LANs, etc. - we're generalizing for the general Internet user). I understand what you're getting at but the original statement is simply incorrect and misleading. The "FTP is more secure" argument is almost certainly false as, at best, vanilla FTP traffic and SMTP traffic are both plain-text and thus offer no security at all. It's much more common for e-mail to offer some level of protection, particularly in the arena of web-based e-mail accessed over SSL. Therefore I think it's fair to conclude that at best the two protocols offer the same level of security and at worst e-mail is "better."
With respect to the topic of "Is FTP better than e-mail for transferring files?" I think the answer is indeterminate. The two protocols and their implementations differ too significantly to offer a simple "yes" or "no." E-mail is definitely more widespread and more familiar than FTP. There are also security differences depending on the specific e-mail service and how it is implemented.
You're welcome to cite some sources that offer opinions on this topic but I think we're better off avoiding the topic altogether as it's complicated, dated, and dangerous for us to steer away from descriptive information to prescriptive information. --ElKevbo 22:11, 30 October 2006 (UTC)
I've written a lot of science articles and I've asked a lot of science editors how to make science writing more accessible, readable and interesting. Steve Petranek, the editor of Discover, told me: "Narrative, super-readability, news, a cosmic paragraph fairly high up on why you should waste your time reading this."
If you want to make this article accessable and readable to the general, non-technical reader, you have to tell them clearly towards the beginning why this article is important to them.
Can you tell me, in language that I as a non-technical reader can understand, why knowing more about FTP could be useful to me?
The benefits of a technology are usually an important part of the introduction to an article. (An article should also discuss the problems or limitations, and the benefits of alternatives, which should make it NPOV.)
The most common reason people give me for using FTP is that, for transfering files, it has certain benefits over email attachments. Is that right? Nbauman 20:09, 31 October 2006 (UTC)
I have no intention of telling anyone "why this article is important to them." This is not a for-profit publication that requires readers to purchase or view our material. This is a scholarly publication
But editors of non-profit and scholarly publications, like Science, IEEE Spectrum, etc. say the same thing. Every article I read in the New England Journal of Medicine, which is scholarly and written for doctors, starts off with a paragraph that explains why this article is important for them. The current Science has an article on high-speed atomic force microscopy, and they start off by explaining why high-speed AFM is important to readers who may not even know why it's important.
and if you're looking at an article then presumably you already know why it's important to you.
Not for me. People told me generally that FTP would be useful for me, and I was trying to find out exactly why FTP would be useful. People go to encyclopedias to find basic information.
A well-written article should entice most readers into reading it but I think it's mistaken to write an encyclopedia with the explicit intention of telling your readers why it's important to them.
But the review articles in Spectrum, Science, NEJM, and other journals are encyclopedic, and they always explain why the subject is important. The editor of Spectrum told me specifically that when she took over she had to change the articles to make them more accessable to their diverse readership, because people weren't reading them.
Quite honestly, most subjects are *not* important to the average reader. This specific article certainly is not important to the average reader, particularly today's average reader.
In that case, why don't you take down the "make it more accessible to general readers" box? Why don't you say in the introduction that this article is not important to the average reader? If something has superseeded FTP, why don't you send them there instead?
With respect to your question, I can offer some more answers but as to where you can find citeable, reliable sources I can't really offer much help. My gut tells me that you'd be better off looking in documents that are from the 90's as FTP has fallen out of favor as e-mail has become more pervasive, e-mail attachment size limitations have risen, and other, more secure and accessible forms of storage and transmission have become more common.
Then why not say in the introduction that the use of FTP has fallen off? Why not send the reader to to those alternatives that have become more common? (BTW what are they?)
Alternatively, do you have a source to support that claim that FTP isn't important? Nbauman 00:42, 1 November 2006 (UTC)
Don't ask for negative proof please, it's a well-established impossibility and will just derail this conversation.
I don't know what you mean by negative proof. I'm asking whether you have any proof that FTP is no longer important, and has been superseded by something else. That's possible. I could find proof and sources (and citeable opinions) that floppy disks are no longer important and have been superseded by other storage media. Why can't you find similar proof and sources that FTP has been superseded?
I don't have any qualms with making this article more readable. However, this particular issue comes down to one question: are there sources? If Wikipedia is going to offer readers a value judgement such as what FTP is good for (not just what it is for), then our hands are tied: we cannot offer this, but must instead quote or paraphrase someone else's opinion on the matter.
I'm trying to find out what the uses of FTP are. There may be other things that also do the same thing, and I'd like to know what they are too. For example, I use FTP to transfer files to my web site. Is that POV? I don't think so. Is there another way to transfer files to my web site? What is it? Does anyone know a source that tries to evaluate whether one is better than the other? If so, put it in. If not, leave it without a judgment.
If you are just personally interested in why FTP is considered better than email for transferring files by some, asking your resident techie would be more fruitful.
No, I don't just want to find out for myself. I want to find out and share it with other people, in language that I can understand. I want to be able to direct non-technical people to this article when they have the same questions I had.
As a resident techie for other people I know what my answer would be, and it is not a simple "A is better than B". It depends very much on what your needs are, what kind of data you're moving, what your computer access and filespace arrangements are, and a number of other factors. This article is not the place to cover such an inherently subjective question unless we can quote others with sources. — Saxifrage ✎ 02:32, 1 November 2006 (UTC)
You mean you're a resident techie and you can't find a source in the entire Internet where someone compares FTP with another protocol for different purposes? Nbauman 03:51, 1 November 2006 (UTC)
If you want this information, then you find it. I wish you the best of luck but badgering others to do your own research for you is not the way to go about it. --ElKevbo 05:39, 1 November 2006 (UTC)
So why not take off the Technical tag?
You don't believe in the whole philosophy behind the Technical tag, you don't wan't to make articles less technical, you don't care whether non-technical readers understand it or not, and you don't want non-technical readers to understand it.
You want it to be unreadable by people who aren't as smart as you.
If somebody else tries to make it more understandable, you'll say it's wrong and revert it — but you won't explain to the contributor why it's wrong, or help the contributor do it right.
Why are you wasting the time of people who are willing to make this entry non-technical? Nbauman 14:16, 1 November 2006 (UTC)
Please calm down, cease the baseless accusations, and tone down the unnecessarily accusatory and combative attitude. If you want to improve this article then by all means continue working to do so. It, like most other Wikipedia articles, could definitely use improvement. Unless my memory fails me (and it does sometimes), I haven't added any templates to this article. I'd like to help but quite frankly there are many other Wikipedia articles in much worse shape on which I am working and keeping an eye on. This article is simply not a priority for me. Best of luck! --ElKevbo 15:13, 1 November 2006 (UTC)
If you can say, as the conversation does above, that you don't think the general reader would be interested in this article, and you don't believe in telling readers why this article is useful to them, then no one can make this article more understandable.
You should delete Technical tag and not ask people for help in editing.
If I had good luck I wouldn't have wound up trying to edit this entry. Bye. Nbauman 17:14, 1 November 2006 (UTC)

[edit] Question

Hi Everyone, I have a question. Is there any limit on the file size that can be transferred through FTP??

No. In future though, see Wikipedia:Reference desk for questions like this. I could be wrong, after all. :) — Saxifrage ✎ 23:28, 1 December 2006 (UTC)
The protocol itself imposes no standards. Most FTP server software will work with any file size without a problem, but some FTP client software will "time out" on long transfers. Notably, Internet Explorer (up through version 6, anyway) is really bad at big FTP transfers; use a "real client" instead. Rpresser 23:32, 1 December 2006 (UTC)

[edit] Anonymous FTP ?

I don't understand, in the article, why trivial FTP or Gopher are "alternatives" to anonymous FTP. How do those address the issues against anonymous FTP? And isn't TFTP only useful in a local network since it doesn't use the reliable TCP? —Długosz

TFTP and Gopher each use a single TCP connection instead of two in the way that FTP does. In situations where anonymous FTP would be used, but might be obstructed due to firewall issues because of the dual connection requirement, TFTP or Gopher can supply the same service -- anonymously retrieving a file without authentication -- to get around the firewall issue.
TFTP can theoretically work wherever UDP works, but you are correct, it is usually only useful on high speed LANs, though this is more due to latency issues -- TFTP only transmits one packet at a time, then waits for acknowledgement, much like the old XMODEM protocol for modems -- rather then because of reliability problems.

[edit] Date/TimeStamp

It seems that it is impossible to upload a file with FTP and retain the original file Date/TimeStamp. I have just wasted a half day trying every possible way. It would be helpful if the article said so in plain terms. And it would be helpful if anyone who knows could at least explain here why there would be such a limitation, and what ways there might be to get around it. I guess one could zip files into an archive and transfer them that way... But I don't know how to get them unpacked at the other end. What a big nuisance! This should be added to the "Criticisms of FTP", by someone who knows more than I do... 69.87.203.244 01:43, 12 January 2007 (UTC)

This ability was not thought important when the FTP protocol was standardized. There is an extension that handles it, draft-somers-ftp-mfxx-01:
"These extensions provide the ability for a FTP Client to modify the last modification time, the creation time, or multiple facts (last modification time, creation time, operating system permissions, etc.) of a file in the server-FTP process NVFS. These extensions are implemented by three new optional commands: 'MFMT' (Modify File Modification Time), 'MFCT' (Modify File Creation Time), and 'MFF' (Modify File Facts)."
However since it is an extension and not the original protocol, servers are not obligated to support this. I've just tested and found that IIS 6 (Windows Server 2003) does not support it, nor does my installation of Fedora Core 4. But a quick web search shows a lot of talk about it, so maybe it's spreading. You can test if the destination server supports it by sending the literal command "HELP MFMT" to the server; your ftp client should have a way to send literal commands to the server. The built-in Windows commandline client ftp.exe does this using the "quote" verb, so you'd type "quote HELP MFMT" after logging in.
Other file transfer methods, like rsync, rcp, scp, sftp are more likely to preserve file facts, though they're also harder to find in the wild. Then there's always WebDAV, which is practically a filesystem. Rpresser 15:23, 12 January 2007 (UTC)
Thank You, Thank You, Rpresser!! 69.87.200.233 12:17, 13 January 2007 (UTC)
The Rcp (Unix) article is a 3-sentence stub -- please help it if you can! 69.87.200.233 12:25, 13 January 2007 (UTC)
Retrieved from "http://en.wikipedia.org../../../f/i/l/Talk%7EFile_Transfer_Protocol_6a8c.html"