User (Old forums)MemberJanuary 21, 2004 at 10:17 amPost count: 23064
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?
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by ominus (had 7143 views)User (Old forums)MemberJanuary 21, 2004 at 11:20 amPost count: 23064
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.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Martin (had 369 views)User (Old forums)MemberJanuary 22, 2004 at 11:00 amPost count: 23064
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
Anyone notice if I’ve made a mistake somewhere?
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by ominus (had 442 views)User (Old forums)MemberJanuary 22, 2004 at 11:43 amPost count: 23064
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>firstname.lastname@example.org</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.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Martin (had 424 views)User (Old forums)MemberMay 2, 2005 at 8:15 pmPost count: 23064
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
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)
Public Overrides Function Seek(ByVal offset As Long, ByVal origin As System.IO.SeekOrigin) As Long
If SeekEnabled Then
Return MyBase.Seek(offset, origin)
Public Property SeekEnabled() As Boolean
Set(ByVal Value As Boolean)
m_SeekEnabled = False
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.SeekEnabled = False
http://ftp.SendFile(fbs, filename, True)
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Kris (had 578 views)User (Old forums)MemberMarch 1, 2006 at 1:03 pmPost count: 23064
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.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by bill.burlison (had 388 views)User (Old forums)MemberMarch 1, 2006 at 2:16 pmPost count: 23064
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.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Martin (had 1381 views)User (Old forums)MemberJune 8, 2007 at 1:37 pmPost count: 23064
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)
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Kurt (had 6970 views)
- You must be logged in to reply to this topic.