• C


I am involved in developing a program with the following specifications.(in Linux)
Whenever I use ftp to fetch a file(get <filename>) if I press Control-C the file should be saved upto that point in the file.I write a footer to the file about the file pointer position .When I try to fetch the same file using get the file should continue transfer from the point it was saved upto and thus the transfer should begin only after the point upto which it was saved.I can only modify the ftp client code.The program should work with existing ftp servers.How will I achieve this (i.e making server send data packets containing the file contents only after a particular byte offset instead of from beginning of the file).Please help me in this regard and also provide general advice on the problem.
Who is Participating?
bertvermeerbergenConnect With a Mentor Commented:
You can restart a transfer from a given point in a file by sending two ftp commands in sequence:
1. REST <restart_mark>
   (response code 350)
2. RETR <filename>
This will cause the sender to skip the file up to the restart_mark and start sending the data from that point on.

The problem is to get the value of <restart_mark> to use.  If you know the byte offset (i.e. the length of the file you have secured on disk at the time ctrl-c was pressed, you can use this value in the REST command.  This works for me between the Win95 client and a Linux ftp server (using the quote command to send the REST, since the Win95 client doesn't implement a restart command directly).
HOWEVER: In RFC959, the talk about restarting a transfer is not very clear on this (for me, in any case).  This RFC seems to state that restart is possible only for block and compressed modes, and not for stream mode.  Or may be I am misreading it and only the special restart markers are used in those modes, meaning you can simply use the byte offset as a restart point in stream mode.  The simple test seems to indicate this possibility.

So, if you can modify the client code, you can consider the following (asuming the byte offsetcan be used with all ftp servers and you are using stream mode):
1. When ctrl-C is pressed, secure the file on disk (close it).
2. On the next 'get' for the same file, use the length of the existing file as the offset in the REST command and the start the retrieve of the file.  Of course, you could (or let the user) decide if you really want to restart, or is you want to ignore the fact that a file under the name already exists.  This depends on your needs, ftp cannot possibly know what you want.
3. Append all data received to the existing file.

sobhan102398Author Commented:
how will I know whether a ftp server supports restart or not.
What about when getting multiple files
restart 1234 //from 1234 byte
get *.c
will I get all c files from 1234 offset
how will I use the byte offset.
sobhan102398Author Commented:
I need to implement the client for linux
so what about <reget>.
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

1. restart support
Well, an ftp server 'should' support since it is part of the protocol.  But, in this less-than-perfect world, one way to make sure is to send the REST command (with any offset, 0 comes to mind).  The answer would indicate if the server understands what you want or not (> 400 indicates failure of some sort, see RFC640 for the FTP reply code structure).
2. multiple get
This is really a client functionality.  The client will first ask the server for a list of filenames corresponding to the mask using the NLST command.  Then, a RETR command is done for every file, just as if the user asked for them one by one.  As far as the restart is concerned, the REST offset is used only in the directly following RETR command.  If your client wants to restart all files in a multi get, it must send the REST/RETR sequence for every file in the list.  The offset to use will of course depend on the status of each file (do you really need to restart all the files *.c from a fixed offset like 1234 ? Remark that you can, by sending REST 1234 before every RETR, but I fail to see a practical use for this).
3. reget (in fact: get and append to an existing local file)
This is the simple case, use the current filesize of the local file (from stat()) as the offset in REST, and append the data coming in for the RETR command at the end of the file.
sobhan102398Author Commented:
1.I want my program to be compatible with all unix ftp servers. they might not support restart. How will I know by program whether a server supports restart option or not
2.Can u provide me sites where I can get ftp client code documentation
1. According to RFC640, a client sending a REST command can recieve following messages:
500 syntax error, command not recognized
501 syntax errors in parameters
502 command not implemented
421 service not available
530 not logged in
350 requested file action pending further information

So, make the client send a REST command, and act on:
350: ok, restart supported by server (and set for next RETR)
502: no go, server does not understand the REST command
other: fix the problem according to list above and try again (if your client is functioning correctly and connected and logged in to a host, only 350 or 502 should be expected).

2. FTP is part of the (linux) netkit package.  The first one I found was at:


(There are plenty of other sources, for example all mirrors of sunsite.unc.edu)
sobhan102398Author Commented:
What about dealing with servers which donot support restart options.(is there any backtrap or any efficient method)
I am afraid there is not much a client can do to make a difference.  The only thing would be to discard incoming data up to 'offset' bytes and than start appending to the existing local file.  But this is not really an optimization since the network will be the bottleneck, not the local disk throughput.
On the other hand, did you already encounter servers that do not support restart ?  Remember that not every one is writing his own server, and the 'common' onces adhere to the standard as defined in the RFC.  Supporting restart is not complicated on the server side (a simple seek in the file to the offset value received in a previous message before starting to read and send the file data), so I wonder why this feature would be left out of any server implementation.

sobhan102398Author Commented:
Ok  thanks . I will inform u on further progress*
sobhan102398Author Commented:
One last query
Is it possible say I don't want to modify the client code.
And I write my own code in a seperate file for handling the get command.
Now I make a DLL with my code.
Can I make the client program connect to my function for handling  put without calling the actual function for put.

I am somewhat confused, but let me try to give you some ideas (for what I can make of the question, sorry if it is not what you mean).

Not modifying the client code and having it call a function you write is possible in certain limited cases:
1. There must be a function for you to replace in the original code (implementing the 'get').
2. This function must be in a source file of its own and compiled as a separate object, to be linked together with other objects to form the client executable code.

If this is the case, you can implement your own 'get' function in a source file, compile it and use this to be linked with all other objects that are part of the original client code, except the one containing the original 'get' function.  This does not use the DLL mechanism but only static linking.
If the original function is not in an object file of its own, you are in trouble.  Linkers typically search for a function in the object files and than link the complete object containing the function, including all other functions in the same object.  If the 'get' function is not in a separate object and you want to replace it, you will have to implement in your source file all other functions in the original object.  If you do not do this, these functions will not be resolved by the linked or, if you still supply the original object to the linker in addition to your object containing your 'get' function, the linker will find multiple definitions for the get function when the original object is linked in for some other function it contains.

Putting your code in a DLL (under Linux ?) would be a solution only if the original function was already in a DLL and you are able to replace this with your own with the same name.  The problem of other functions in the original DLL is somewhat similar to the linking described above.  You could try making your DLL call the original functions through stub routines, but the DLL name (original the sameas the new, and you cannot just rename a DLL and keep on using it).

If this is not a response to your question, please state it more clearly and I will do my best to answer it.
sobhan102398Author Commented:
What I asked was
I donot modify the client means I am not taking care of the ftp client program or its code. The ftp client program is the executable client that is provided with linux which will not be changed. Now if in the ftp program if I use get command it executes the sub function meant for it. Now if I write a similar get sub function in a seperate file,can I make the ftp client to call my function instead of the original.  
I understand what you want now, but I do not see any solution for it.  While it is true that in theory you can write a 'get' function in a dynamic linked library and replace the original library containing this function (and only this one), in practice I do not know of any implementation that is really written in such a way.  Although it might be a nice feature to have in your case, I do not think anyone writing a general FTP client will implement all the functions in separate libraries, just in case someone would like to replace a single function.  Many implmentations will not even have a single function to handle a 'get' or any other command, so it would not be a trivial task to modify such a program to fit your need.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.