If I use InternetConnect, then I can call FtpFindFirstFile,
InternetFindNextFile and FtpGetFile to do all the work. But, the
InternetConnect requires specific server, dir, and port parameters,
and does not take a URL like "ftp://servername/subdir:port" .
So, I decided to use InternetConnectURL because this routine will
accept the ftp URL instead of requiring me to parse the url into
separate components (server, port, etc) as needed by InternetConnect.
Well, apparently InternetConnectURL returns a different handle than
InternetConnect?!? Note, I am using the INTERNET_FLAG_RAW_DATA flag.
When I use the handle returned from InternetConnectURL, I cannot call
FtpFindFirstFile. This results in an
ERROR_INTERNET_INCORRECT_HANDLE_TYPE error. Instead, I can use
InternetFindNextFile to enumerate the list of files. That works
fine, retrieving the files on the server in a WIN32_FIND_DATA
structure. But now, if I try to download one of these files, I
cannot use this same handle for FtpGetFile, it too gives the
ERROR_INTERNET_INCORRECT_HANDLE_TYPE. Ugh.
So, is it true that if I want to use FtpGetFile, I cannot use
InternetConnectURL? Is there something simple I'm missing?
PS: I'm coding this in VC6.0 for W2K & XP systems.
Yes, handles opened using InternetConnect behave differently from those
opened using InternetOpenUrl, even for the same protocol. That's just how
WinInet works.
If you need FtpFindFirstFile to work, you need to use InternetConnect.
Don't forget that you can parse the URL and decide what to do based on that.
If you have an arbitrary URL, you don't *have* to pass to InternetOpenUrl
just because you can.
Paul
<Paulaner> wrote in message
news:g701e2h56salvj7i5...@4ax.com...
Thanks for the response. One followup: Is there a handy routine to
parse the URL into the various pieces: protocol, user/pass, server,
dir, port? I found AfxParseUrl, but that seems to need new headers
and libraries linked in. Do I just write my own?
I have to say, having read the documentation for INTERNET_FLAG_RAW_DATA, I
cannot tell what it really does.
Paul
<Paulaner> wrote in message
news:5oj1e2lu7p88re4gt...@4ax.com...
WIN32_FIND_DATA ftpFileData;
szURL = "ftp://server/path";
...
hSession = InternetOpen("InetURL/1.0", INTERNET_OPEN_TYPE_PRECONFIG,
NULL, NULL, 0);
if ( hSession)
hConnection = InternetOpenUrl( hSession, szUrl, NULL, NULL,
INTERNET_FLAG_EXISTING_CONNECT | INTERNET_FLAG_RAW_DATA, NULL);
... error handling...
//Get list of files from server
while(InternetFindNextFile(hConnection, &ftpFileData)) {
if ((ftpFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) !=
FILE_ATTRIBUTE_DIRECTORY)
{
// Copy ftpFileData.cFileName
...
On Mon, 14 Aug 2006 16:11:29 -0400, "Paul Baker [MVP, Windows -
I am therefore wondering what the usage of INTERNET_FLAG_RAW_DATA really
is? It is not clear to me from the documentation.
What happens if you use InternetOpen and InternetOpenUrl exactly as you
have, but then use InternetReadFile to read it as if it were a file? Do you
get a series of WIN32_FIND_DATA structures? If so, you have what you need,
don't you? :)
Paul
<Paulaner> wrote in message
news:t2p1e2d0g8r59g1k2...@4ax.com...
InternetCrackUrl
InternetOpen
InternetConnect
FtpFindFirstFile
FtpGetFile
while(InternetFindNextFile)
FtpGetFile
I'll probably go to the InternetReadFile option in the next version of
this application, because I should support ssl file transfers. The
anonymous access ftp (or cleartext password) can become an issue at
some sites.
Thanks again for your insight.
On Tue, 15 Aug 2006 11:09:40 -0400, "Paul Baker [MVP, Windows -
Paul
<Paulaner> wrote in message
news:7lu3e2d70trlblp1m...@4ax.com...