Home Forums .NET libraries Xceed SFTP/FTP for .NET Resuming a file

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #20616 |

    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

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by ominus (had 7143 views)

    User (Old forums)
    Member
    Post count: 23064

    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.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Martin (had 369 views)

    User (Old forums)
    Member
    Post count: 23064

    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

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by ominus (had 442 views)

    User (Old forums)
    Member
    Post count: 23064

    Hello Joel.

    That’s indeed a problem. I’m using a <a href=”http://doc.xceedsoft.com/products/zipNet/ref/xceed.filesystem.streamfile.html”&gt; 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&gt; 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.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Martin (had 424 views)

    User (Old forums)
    Member
    Post 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
    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
    http://ftp.SendFile(fbs, filename, True)

    Regards,

    Kris Sheglova

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Kris (had 578 views)

    User (Old forums)
    Member
    Post 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)
    Member
    Post 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)
    Member
    Post 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)

    Thanks
    Kurt

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Kurt (had 6970 views)

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.