[RESOLVED] Access a subdirectory in an ftp://

Hi !

I am web admin in an association, and one of my duties is to respond on files sent to a sub directory in the ftp:// of the web hotel we use for our website. Then I make a list from parts of this file and put the list on a certain place on the website for information to our members.

I have mapped the "ftp://[email protected]/" to a network drive (OurWebsiteName) on my computer, and I'm constantly logged in on it, so I don't need to use password and user name !
Attachment 101083

There is no problem for me to, on daily basis, open the network drive, look up the subdirectory (can take a few seconds !), check if there's any file to care about and work on it. Then I just delete the file and close the drive again...

But I can't find any solution how to reach the ftp:// and its subdirectory with a VB-program, even how to make the program patiently wait the seconds it usually takes to open....

What I want is to programmatically search the directory with a program started by the computer regularly, and flash a message if there is any file, maybe even copy it for me.
I already use a similar program for other purposes, and it works fine. Would like to complete it with access as described above...

Best regards and thanks for any attentions

/Kalle

Search about BrowseForFolder API
Or http://www.xtremevbtalk.com/showthread.php?t=138529
Or http://vbnet.mvps.org/index.html?cod...wsefolders.htm

i have done an example for looping through all subdirectories on an ftp site, it may help you
there are 2 samples, one using API, the other using a shell object, the latter will work with both remote or local directories

http://www.vbforums.com/showthread.php?t=649292

Many thanks, jggtz and westconn1 for your suggestions ! :)

jggtz: It was a bit difficult to put my simple need to check for the presence of a file in a single directory into the fairly extensive programming that must be performed to find a directory on ftp...

westconn1: I will look through your links more accurate. They seems rather interesting!

But what's difficult to understand is, that when I already have the ftp structure represented in my Explorer, and also just in a simply way manually can open the directory and verify the existence of any file with a few clicks - why am I not able to do the same with a VB program code, without having to basically log in from the start with a user ID and password to access the same endpoint, since I'm already logged in ? Why can I not use my existing access ?

It looks like the only reason for a normal access to fails is the lack of a drive letter for the ftp-drive (! ?) Therefore I've also looked at a Netdrive, that maybe could be helpful. It should at least give me a letter för de ftp-drive ! (?)
But probably anyway, at every boot of the computer, I have to use username and password, which isn't a problem in itself. What however worries me is that I, with ev'ry logoff, might lose my convenient direct connection I now have to ftp, and therefor must struggle with login details again and again at ev'ry new opportunity, which may not have anything with the above management to do ... I know that something similar has happened before !

Best regards

Karl-Erik

Quote:

---

It looks like the only reason for a normal access to fails is the lack of a drive letter for the ftp-drive

---

a mapped drive should have a driveletter already, but a unc path should work as well

Quote:

---

why am I not able to do the same with a VB program code, without having to basically log in from the start with a user ID and password

---

you probably can, but as the username and password can be in the code, it hardly seems an issue to use them each time

without having a similarly mapped drive to a ftp site, it is hard to test why you are having an issue, with your existing code

there are many examples of using a shell object, for both local and ftp, in this forum, several by me

it works the way it does because explorer has a built-in FTP client... that's why it works that way... when you then try to access it through another program, it doesn't have knowledge of other ftp clients running... and it's a new connection, so the credentials have to be asked for... plus if you think about it... do you REALLY want OTHER programs lurking around, able to sniff out an FTP connection through your file browser and then USE THAT CONNECTION!? You'll find that under FTP-Exploits in the book "Recipes for Disaster"...

Asking VB to use the FTP connection used by Explorer is like asking VB to use the FTP connection FileZilla has open...

-tg

Quote:

---

Asking VB to use the FTP connection used by Explorer is like asking VB to use the FTP connection FileZilla has open...

---

not really, using a shell object you can automate explorer, including already open explorer windows

Back to Basic !

I thought I found some 'good' solution in internet, from where I could log in on a certain ftp-site, and possible see if there was a file for me...

At first I made sure I had the right ftp address. Then I tried it on FireFox. No problem at all to get to the site, as waited for me to log in with my username and my password.
The result was an information that there was a file waiting...

Attachment 101257

('Classified' information are overwritten....................)

OK - Back to the program

Declarations

Code:

---

Private Declare Function InternetOpen Lib "wininet.dll" Alias "InternetOpenA" _
(ByVal sAgent As String, ByVal lAccessType As Long, ByVal sProxyName As String, _
ByVal sProxyBypass As String, ByVal lFlags As Long) As Long

Private Declare Function InternetConnect Lib "wininet.dll" Alias "InternetConnectA" _
(ByVal hInternetSession As Long, ByVal sServerName As String, _
ByVal nServerPort As Integer, ByVal sUsername As String, _
ByVal sPassword As String, ByVal lService As Long, _
ByVal lFlags As Long, ByVal lContext As Long) As Long

Private Declare Function FtpGetFile Lib "wininet.dll" Alias "FtpGetFileA" _
(ByVal hFtpSession As Long, ByVal lpszRemoteFile As String, _
ByVal lpszNewFile As String, ByVal fFailIfExists As Boolean, _
ByVal dwFlagsAndAttributes As Long, ByVal dwFlags As Long, _
ByVal dwContext As Long) As Boolean

Private Declare Function InternetCloseHandle Lib "wininet.dll" (ByVal hInet As Long) As Integer

---

-------------------------------------

Program:

Code:

---

Private Sub Form_Load()
Dim lngINet As Long, lngINetConn As Long, blnRC As Boolean

lngINet = InternetOpen("MyFTP Control", 1, vbNullString, vbNullString, 0)

lngINetConn = InternetConnect(lngINet, "ftp://ftpcluster.'webhotel'.se/", 0, _
"username", "password", 1, 0, 0)

blnRC = FtpGetFile(lngINetConn, "*.*", "C:\Temp\*.*", 0, 0, 1, 0)

InternetCloseHandle lngINetConn
InternetCloseHandle lngINet
End Sub

---

Nothing happened ! Never reached the line "blnRC..." !

lngINetConn turned out to be zero...

Is it possible that the program is too fast, and doesn't wait enough long time for the ftp-site to respond. To check this out I put a loop around the login and a delay in between. But the result was the very same...

What is going wrong here ? Is it complete impossible to make a program for getting a file from ftp ?

/Karl-Erik

Quote:

---

What is going wrong here ? Is it complete impossible to make a program for getting a file from ftp ?

---

see the link i posted above, it gives some information about using internet APIs with subdirectories, i believe, you have to call internetopen each time you change directories

personally i would do like

Code:

---

      initdir = "ftp://username:[email protected]"    ' change to suit
      myfile = "some file name"    'change to suit
      Set sh = CreateObject("shell.application")
      Set n = sh.namespace(initdir)
      set f = n.parsename(myfile)
      if not f is nothing then    ' file found

---

What you have there is not a mapped drive, but an Explorer "Network Place" or "Web Folder" which is a horse of an entirely different color.

FTP is notorious for being an insecure, stateful, meant to be user-attended, flaky way to transfer files. For this reason Microsoft has never provided more than minimal support for it, and instad helped developer WebDAV instead. However since PHP on Apache had terrible warts for many years which broke Apache WebDAV support , WebDAV never got the traction it might have because of so much use of el-cheapo LAMP hosting. Of course WebDAV is still all over the 'net, widely used for things like program source control and collaboration servers.

But I'm guessing you have some sort of this el-cheapo hosting so you are stuck with FTP.


Thrashing around trying to use the WinInet API usually isn't worth the trouble. It tends to only be useful in degenerate cases with a few and/or very small files because the async part of the API is hard to use - so people try to limp along with the synchronous calls discussed above. These synchronous calls tie up your program's UI thread for long intervals with all sorts of negative consequences.

When Microsoft created the Internet Transfer Control (ITC, a.k.a. INet) they tried to wrap most of the hard stuff for VB6 programmers. This works well enough for HTTP and Gopher, but not so much for the always-problematic FTP protocol. However if you're aware of some of the weird things going on under the covers there are ways to more or less make it all work.


A while back I wrote a wrapper class for the INet control (actually a UserControl since INet must be hosted in a container) that deals with some of the quirks and uses a sort of "job queue" approach to help smooth out the bumps.

Here's a demo program that uses it to do sort of what you seem to be asking for. During the session it creates and runs one "job" to establish the connection, change the current directory, and retrieve a directory list. On completion it creates and runs a second "job" based on the returned list of files that downloads each file to a local directory and deletes each file from the server. Then it logs off.

Attachment 101267

It seems to be fairly smooth and reliable. This wrapper has several timeouts you can specify so that it doesn't hang too long on short requests nor abort if you need to do lengthy file transfers.

Thanks all again for different suggestions and your patience !

dilettante:
The program is stopped here, unless I've any subdirectory named or not !
On line "Inet1.Execute , CurrCmd"

Attachment 101285Attachment 101287


Anyway;

My current method to find and use a file in the certain ftp-directory is to first open an already logged in directory (in my explorer) - as described in my first post - to see if there is anything. It's not so much trouble and it can be done rather smoothly.

What I try to find out, is how to create a program that schematic looks for me in that same directory - say once in a couple of hours - and when there is a file, the program will tell me about it with some flash or something... Then I don't have to look now and then myself....

I already have created other similar program looking for i e visitors on my homepage, visitors at my different programs and so on, and they works very satisfying. Maybe I'll combine them all later to one and only program...

So - please understand me - I'm not very interested in creating yet another method to click my way to the very same directory I already can reach with a few click - as described above.

My knowledge is a bit poor, that's why I'm still puzzled about why I cannot use VB6 to do the same thing that I do when opening a directory on my Explorer...
But if there is no way out of this - well - then I have to continue click me in to the directory that maybe contains a file - maybe not....

/Karl-Erik

IMO the DIR function should do the trick
...using the path as "\\ServerName\MyDir\"

Quote:

---

Originally Posted by Karl-Erik

The program is stopped here, unless I've any subdirectory named or not !
On line "Inet1.Execute , CurrCmd"

---

Thanks. That condition should have been trapped. It is now (attachment above reposted with correction).

However it doesn't explain why you can't connect. Maybe you didn't provide a correct server DNS name or IP address? You can't just use your "Web Folder" name which could be anything you choose to make up.

As far as I can tell Web Folders are not supported "out of the box" after Windows XP. Installing Office 2000 or later may add the feature, but it may still be broken in Windows 7 (there was a fix for XP and Vista but not Win7).

Web Folders / Web disk / WebDAV problems on Windows 7

So you probably don't want to use the feature at all anyway.

Hi dilettante !

I've actually got your demo program to work!
I don't know why it didn't work at first, maybe I typed something wrong before ... Yet, I haven't downloaded your supplementary modification regarding error handling!

But now it's actually show in the window which files exists in the FTP directory!
It's a great success since my attempts with ftpGetFiles were difficult to program because the files to be retrieved is not the *. *, I e they have no last name. Then they were never found by ftpGetFiles with search on "*. *". Now I at least know the file names and can perform a specific command !

This program "WrapInetFTP" is written far above my own capacity, therefore the following questions:

When the program finds files, will there occurs any copying at the same time, that I can use and extract ?

If not, how can I conveniently extracting file names from the application to use in a main program with ftpGetFiles?

My idea is to run a main program with ftpGetFiles calling "WrapInetFTP". When filenames are found to retrieve, the main program can collect and process them, otherwise it goes on with another searches....

With greeting and a big THANKS !

/Karl-Erik

Glad to hear you are getting some results.


How VB Programs Are Written

Where to begin?

You need to realize that Windows programs' user interface threads are what are called State Machines. In classic VB all of your code runs on the UI thread so your programs must be written as state machines.

This means you can't write "straight line" QBasic style code in VB or else you have problems like the UI becoming unresponsive to Windows. People will try adding hacks to avoid writing a proper state machine (like busy-wait loops calling the evil DoEvents function, sometimes in combination with calls to the Sleep API). But these almost always lead to performance problems, stack overflow crashes, lost data, or corrupted data.

Instead we need to wait for Events (Form load, button click, etc.), then do a little processing and modify our state, then go back to awaiting a new Event of some kind. Sometimes we need to cause a deferred Event so we can check on the progress of some external process or resume processing part of a "batch" workload. This is why VB has a Timer control (which isn't for "timing" things at all).

This "waiting" is handled by the message loop, which is code inside the VB runtime that you don't see. The message loop is what calls your event handlers. Your code "resumes waiting" by exiting the current event handler.


Demo Program

In the demo Project the actual work to be done is determined by the code in DemoForm.

When the button is clicked the server, user, PW, etc. are provided to WrapInetFTP, and the first job is created and executed. The first job is just a CD command followed by a DIR command. When the response to the DIR is received and recognized (in the WrapInetFTP_Response event handler), it gets split up into an array of file names.

When job completion is signaled (WrapInetFTP_Complete event handler) a download folder is created if it doesn't exist. Then the array of file names is used to create and execute the second job: a series of GET and DELETE commands.

In the Response handler, which command created a given response is determined from the Command argument passed to the event handler.

In the Complete handler, which "job" has completed is determined from the Tag property value set before calling the Execute method each time.


So the "copying" is handled by adding GET commands to the queue of commands to be executed by WrapInetFTP, which in turn forwards them to the INet control for actual execution. After DemoForm sets up and dispatches a job all it does is monitor for responses and completions and handle those.


The WrapInetFTP UserControl

Ideally WrapInetFTP would be perfect and you would never look at the code there at all except to determine what calls to make. The comments at the beginning of WrapInetFTP should help make it less necessary to read the actual code there to figure it out.

But the reality is that WrapInetFTP has not been used in enough different cases to find 100% of the bugs that may be lurking there. An example is the one you found previously (fixed now as far as I can tell by testing). Given this reality you probably do want to understand what is being done in WrapInetFTP so you can fix errors there yourself if ever required.

The good news is that there really isn't much code there. Some of it is just UserControl "housekeeping" you can ignore after reading it once. Of course to do that you need to understand UserControls. The important code there just handles dispatching FTP commands to INet and then monitoring for their completion and returning responses to the control's container (Form). The monitoring is done two ways in WrapInetFTP: by handling Inet StateChanged events and by using a Timer control to manage timeouts and catch completions that don't get signaled via the StateChanged event.


Or Roll Your Own INet Code

The basics of using the INet control aren't very complex on their own and you could just skip using WrapInetFTP and write your own INet control code. The problem is that FTP is a balky protocol to automate, and this is why WrapInetFTP was written: to encapsulate a lot of the little extras you need to do to make it work reliably. Having this UserControl makes it fairly quick and easy to add FTP to many programs using FTP to do different things.