A few questions from a new user

Hi,

I downloaded 1.0.1.30 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.

Thank you,
Craig

Hello ...

>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.

>FEAT
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.

>OnTransferProgress
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.

Regards,
-Mat
SmartFTP

Thank you for the fast reply.

> 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.
Why not?

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.

Thanks again,
Craig

Why isn't there an ftpLISTOptionRecursive flag? SmartFTP 1.5 supports recursive listings, so I'm assuming it's available somehow. If adding support for it would make the API messy, how about an option to load a file into an FTPDirectory structure, in which case we'd handle splitting the file on directory boundries ourselves.

Thanks,
Craig

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.

Hehe, remember my words, mb?

Hello ..

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.

>ACCT
Will be implemented in the next public release

>Windows 95
It's not supported and I don't know if it runs on this out dated OS Probably not.

-Mat

> The library nor SmartFTP 1.5 supports recursive listings.
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).

Thanks again,
Craig

SmartFTP 1.1 had its own FTP engine built-in, while SmartFTP 1.5 now uses the (also separately available) SmartFTP FTP library. So recursive listings were not removed on purpose because they were buggy, the feature just got lost during transition. If I understand mb correctly, he does not plan to add recursive listings to the FTP library itself, but it will be re-added to SmartFTP 1.5.

One of our test servers (ProFTPd/Linux) doesn't notice an ABOR command unless the special OOB handling is performed. Judging from the forums SmartFTP used to do this, but testing the library and SmartFTP 1.5 it appears that it's been removed. As it is the transfer continues until the server finishes sending the file, though the progress reporting does stop. Calling abort a second time does make the ABOR go through, so I'm guessing the library disconnects the data connection if it's already sent an ABOR command. Is that correct?

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?

>OOB
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).

>ABOR
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.

-Mat

>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.

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?

Thanks,
Craig

>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?
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.

-Mat

The new version 1.5 is now available.

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.

Regards,
-Mat

I noticed you added an ftpLISTOptionRecursive, but I don't see any way to use it. If I set it it just includes all of the items as a single directory without any path information. Am I missing something?

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?

>Recursive
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.

References:
http://msdn.microsoft.com/msdnmag/issue ... fault.aspx
http://msdn.microsoft.com/library/defau ... ewinxp.asp
http://weblogs.asp.net/grobinson/archiv ... 96158.aspx