A few questions from a new user
Posted 17 June 2005 - 09:20 PM
I downloaded 188.8.131.52 a week ago, and I have a few questions.
Why are there seperate RenameFile and RenameDirectory functions? Don't they both map to the same RNFR/RNTO commands?
Is there any way to access the server's FEAT response or make the MLST support conditional on the available facts? I'd like it to only use the MLST command if the "type", "size", and "modify" facts are available and use the regular listings if they aren't.
Is the lack of a CDUP function intentional?
I'm using Delphi and it seems to have messed up some of the callback interfaces. For example, OnTransferProgress was imported as a TNotifyEvent, which only passes the sender in and not nBytesTransferred. I think it's a problem with the Int64's, though some of them (eg, OnDownloadFile) were imported correctly.
Posted 17 June 2005 - 11:27 PM
>Why are there seperate RenameFile and RenameDirectory functions? Don't they both map to the same RNFR/RNTO commands?
It's the same code for both functions but each one has a different event. e.g. RenameDirectory fires a OnRenameDirectory event.
You are right, the library is lacking a function to get the raw FEAT reply. Will be added available in the next release as well. But you don't have to care that much about the MLST facts. All servers I've seen support the 3 basic facts.
>Is the lack of a CDUP function intentional?
It's not really recommended to use CDUP. But we added the function for completeness now. It will be available in the next public release.
We changed the event in the latest build. You can get the bytes transferred from the LastBytesTransferred property.
I hope this helps. Thank you for your posting.
Posted 20 June 2005 - 03:45 PM
> You don't have to care that much about the MLST facts. All servers I've seen support the 3 basic facts.
Sorry, a better question would have been: does the library send an OPTS MLST command to make sure it gets those three facts if they aren't included by default? That's really all I need.
> It's not really recommended to use CDUP.
On a vaguely related topic, does the library support any way to parse paths in some way and rebuild them to send to the server? I completely understand if that's another "don't do it", but if you have code it would be handy to have.
One last thing: Is the library just unsupported under Windows 95 or will it not run at all? If it's the latter, is there any way to get it to run (say, install IE4)?
Edit: Just found another thing: If the server responds to a PASS command with a 332 you need to follow up with an ACCT command. Is that supported? I couldn't find a property that would allow setting the value beforehand or an event handler that would allow us to prompt the user for it if/when it's required.
Posted 20 June 2005 - 08:33 PM
Posted 21 June 2005 - 06:47 AM
Hehe, remember my words, mb? ;-)
Edit: Just found another thing: If the server responds to a PASS command with a 332 you need to follow up with an ACCT command.
Posted 21 June 2005 - 02:31 PM
The library nor SmartFTP 1.5 supports recursive listings. There are no plans to implement it directly in the library. A workaround is planned to get at least the data from the data connection.
>The library doesn't offer any path parsing methods. This has to be done by the user.
Will be implemented in the next public release
It's not supported and I don't know if it runs on this out dated OS :-) Probably not.
Posted 21 June 2005 - 10:15 PM
AFAICT, previous versions of SmartFTP did support recursive listings. The 1.1 version available on Download.com has it in the Options->Transfer, and the 1.5 release still lists it under Commands->Connection->List Options, though it doesn't appear to do anything anymore. I couldn't find any reference to its removal in the changelog; was the server support too buggy to make it worthwhile?
The only other problem I've run into so far is that SetFileTime is returning ftpErrorUnknown even if the server responds with success (253).
Posted 22 June 2005 - 07:46 AM
Posted 22 June 2005 - 03:42 PM
In the previous FTP library we were using the ABOR command was sent normally (not OOB) and then the data connection was forcibly disconnected. That seemed to work well on all of the servers we tested, and it appears the equivalent in the SmartFTP library would be to always call Abort twice in a row. As far as you're aware, will that work correctly and is there any reason why SmartFTP and the library don't do that already?
Posted 24 June 2005 - 12:14 AM
The OOB caused more troubles because most servers do not implement it. Thats why we removed it after SmartFTP 1.1 (even in the old FTP engine).
You may want to send a custom command with the "Command" method of the IFTPConnection interface. First send Command(L"ABOR") and then call the Abort() method. This should have the same behavior as two aborts.
Posted 29 June 2005 - 09:51 PM
If it has the same behavior as calling Abort twice why would I want to do it this way? And more importantly, why isn't it done automatically in response to the first Abort call?
When are you planning on releasing a new trial version? Can we use the version from the SmartFTP 1.5 distribution instead until something official is released?
I noticed the library jumped from 1.4MB to 2.2MB in the SmartFTP 1.5 release, which was presumably due to the MTA/STA changes. Have you considered splitting them into two libraries to keep the size down?
Can you repeat the problem I mentioned with SetFileTime returning ftpErrorUnknown even if it's successful?
Posted 30 June 2005 - 12:43 PM
ABOR is not sent when uploading, only when downloading. What I suggested was a workaround for the specific server you are having problems with. Aborting a data transfer is considered tricky especially with all the different server implementations. Thus for the Global Queue implementation in SmartFTP we never reuse a connection after the data transfer has been aborted.
>When are you planning on releasing a new trial version? Can we use the version from the SmartFTP 1.5 distribution instead until something official is released?
As soon as the documentation is completed. ~ 1 week.
>I noticed the library jumped from 1.4MB to 2.2MB in the SmartFTP 1.5 release, which was presumably due to the MTA/STA changes. Have you considered splitting them into two libraries to keep the size down?
It's not related to the STA/MTA changes.
>Can you repeat the problem I mentioned with SetFileTime returning ftpErrorUnknown even if it's successful?
The problem has been fixed.
Posted 13 July 2005 - 11:44 PM
You are generally not allowed to distribute any files which come with the "SmartFTP Client" product.
The debug symbols take a little bit more space but assuming you are distributing your software in a compressed form the overhead is around 100 KB. We will consider removing the debug symbols in the future if they turn out to be less helpful than expected.
Posted 14 July 2005 - 08:48 PM
Edit: Delphi handles most COM stuff automatically, so sorry if this is a newbie question: Will having both SmartFTP and this library installed cause any problems? I noticed SmartFTP forcibly registers it's own copy of the library every time it starts. Should we do the same thing in our program?
Posted 14 July 2005 - 10:54 PM
You need to split up the listing by yourself. You can use the IFTPParser interface to parse the lines. The tpLISTOptionRecursive only adds the -R flag to the LIST command.
>Side by Side Assembly
If you are running Windows XP or higher, the SmartFTP client doesn't register the type library (sfFTPLib.dll) and there won't be any conflicts with other installations of the sfFTPLib.dll. If you run it on Windows 2000 or lower, the SmartFTP client will automatically register the dll everytime it starts. Running the SmartFTP client and other applications using the sfFTPLib.dll on these systems may cause problems. This is a common problem with COM (ActiveX) components. For more information and solutions please see the references below.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users