Mimiko

Remy, thanks for your detailed reply. For your first question about rename/move instead of copying: The destination file can be elsewhere and is usually on another drive or even on another computer (network share). Unfortunately, the handling is fixed from the client side, so there's no option to implement an API or REST for copying the file. To understand it better, I placed some debug logging into my (non-production) code. So I can trace what's happening if a client's sending a file: CreatePostStream, CreateSession, SessionStart, CommandOther (once!), DoneWithPostStream, SessionEnd. I see that CommandOther is called once, regardless of the file size, and that's why I placed the copy operation there. Or is it possible to put that into DoneWithPostStream? However, I'll try to review the CopyFrom (as you suggested) and I'll try to use a TBufferedFileStream for those file operations. Maybe there's a way to improve handling by optimizing components and transfer, so I'm able to transfer larger files (even if not ANY size). I'll be back with results soon. TIA Michael

I need to do some maintenance on an older project, which has been built using Delphi 10.3 32bit (some components just exist for this version). The Project is using TIdHTTPsServer to communicate and to transfer (upload) files. In CreatePostStream originally a TMemoryStream has been created, but it can't transfer more than approx. 500-600 MB. So I started to use a (modified) TFileStream instead (modified=extended to have LoadFromStream/SaveToStream and the like). The filestream creates a unique temp file where the data goes. Within ServerCommandOther the data is written to a second filestream with the final filename (the final name isn't yet known on CreatePostStream, so I need to copy later). As long as the data is within a 500-600 MB range, all works well. If the uploaded data is larger, then the client gets a network timeout after a few seconds. But the session thread is still active and the copy process is still running. Copying between PostStream and TargetStream is done via CopyFrom and so I placed some logging within its Read/Write loop. As soon as the copy process goes beyond the mentioned 500-600 MB, that loop seems to stop its process for several seconds, then it resumes copying, and this repeats randomly. Finally the file is copied with its full size, but the client's already gone. I just don't understand why THTTPsServer closed the connection while the thread's still working. Is there something I can do to the session or the server to avoid the network timeout at the client? Or is there a problem with TFileStream regarding threads? Indy's reporting 10.6.3.11, so this isn't very old. I tried setting all possible timeouts (ConnectTimeout, ReadTimeout, WriteTimeout on the session socket), enable/disable nagle, KeepAlive, ReuseSocket... all that, but to no success. Is there something I didn't see or are there some dont's I didn't realize? TIA Michael

Hi there, we're trying to use TIcsFtpMulti to upload and download files from several FTP servers. All's working well except when using file paths starting with \\?\ (for use with devices that have no drive letter and no label assigned). Some methods check for Pos('?', someVar) > 0 to raise an error. Could this possibly be extended to ((Pos('?, someVar) > 0) and (Copy(someVar, 1, 4) <> '\\?\')) as a workaround? I'm just wondering that nobody else's got there already. We're using V 9.3 from GetIt Package Manager (D12) - OverbyteIcsFtpMulti is still V 9.1. TIA Michael