Hi

I'm transferring some pretty big files using Xceed FTP for .NET, so I'm needing to be able to resume an upload (my application uploads files only) should the transfer fail. How would I go about this?

Thanks

Joel

Hello Joel.

The FTP protocol exposes a notion of "offset" when it comes to receiving a file, but not for sending. What you need to do is append to the existing file. Let's say you transfer a file, and the connection is lost. Here is what you can do:

- Reconnect (!)
- Check how much bytes were successfully transferred using <b>GetFolderContents(filename)</b>.
- Create yourself a <b>FileStream</b> around your local file.
- Seek at the number of bytes already on the server.
- Call <b>SendFile(yourstream, filename, true)</b>.

I'll take note that it could be a good feature to support a <b>SendFile</b> overload that does all this for you.

Hi

I've done as you suggested and used a FileStream. However it appears that your FTP for .NET component sets the passed Filestream's Position to 0 before sending the data, making seeking to the position in the file to resume uploading from pointless.

Unless I'm making some kind of fatal mistake in my code somewhere, but as far as I can see (and the three people that I've spoken to), there's nothing wrong with my code, so there must be something wrong in the Xceed FTP for .NET code.

here's my code

Int64 TheOffset = GetRemoteFilesize(RemoteName); //Returns the filesize

fs = File.OpenRead(LocalFile); //opens the file on the local machine

fs.Seek(TheOffset,SeekOrigin.Begin); //seeks to the location to resume from

m_ftpClient.SendFile(fs,RemoteName,true);

fs.Close();

Anyone notice if I've made a mistake somewhere?

thanks

Joel

Hello Joel.

That's indeed a problem. I'm using a <a href="http://doc.xceedsoft.com/products/zipNet/ref/xceed.filesystem.streamfile.html"> StreamFile</a> underneath, and it DOES seek to the beginning of the stream upon an <a href="http://doc.xceedsoft.com/products/zipNet/ref/xceed.filesystem.abstractfile.openread.html">OpenRead</a> request on it.

Send an email to <mail>support@xceedsoft.com</mail>, they will assign you a case number, and we'll fix this as soon as possible.

If you need a quick workaround, tell them and they will send you back a <b>WindowStream</b> class I've made myself for the internals of <b>Xceed Zip for .NET</b>. It exposes part of a stream as another stream.

I've noticed that this issue reported back in January doesn't appear to have been fixed, or at least the current installation available from the downloads doesn't have a fixed version of the component. Do you know if this problem has been resolved within the component itself?

For those who have been having the same problem here is a solution in vb.net (note: I consider this a potentially risky solution as I have no idea if the component calls the stream Seek method while transferring files through a stream other than prior to the transfer)

Public Class XceedBugFixStream
Inherits IO.FileStream

Private m_SeekEnabled As Boolean = True

Public Sub New(ByVal path As String, ByVal mode As System.IO.FileMode, ByVal access As System.IO.FileAccess)
MyBase.New(path, mode, access)
End Sub

Public Overrides Function Seek(ByVal offset As Long, ByVal origin As System.IO.SeekOrigin) As Long

If SeekEnabled Then
Return MyBase.Seek(offset, origin)
Else
Return MyBase.Position
End If
End Function

Public Property SeekEnabled() As Boolean
Get
Return m_SeekEnabled
End Get
Set(ByVal Value As Boolean)
m_SeekEnabled = False
End Set
End Property

End Class

To go about resuming the transfer you transfer using the stream as described above but using the XceedBugFixStream instead of a FileStream:

dim bfs as XceedBugFixStream

..
..

offset = GetRemoteFileSize(fullRemotePath)
bfs = New XceedBugFixStream(fullLocalPath IO.FileMode.Open, IO.FileAccess.Read)
bfs.Seek(offset, IO.SeekOrigin.Begin)
bfs.SeekEnabled = False
ftp.SendFile(fbs, filename, True)

Regards,

Kris Sheglova

Has this issue been resolved?

The knowledge base says:

To resume transfer where it left off when using the .SendFile method, simply set the Append parameter to true.

When I tried this, it appended to the end of the file but started again at offset 0. So it is not actually resuming where it left off.

The knowledge base is misleading. The "append" parameter says that the content of the file to send will be appended at the end of the destination. But it will append the full contents of the source.

To resume sending a file, you must open a stream on that file, seek to the proper offset, then pass that stream to the SendFile overload that takes a Stream instead of a filename. Transfer will continue at that stream's position. That's where there used to be a problem. This overload was seeking the stream back to the beginning, which it shouldn't have done. This is fixed.

Would you please consider implementing this as an overload to the send file method.

This would be a very useful feature that would save a good amount of time.

So SendFile(filename, append, resume)

Thanks
Kurt