cFTP:Directory() 2.6
Gary Miller
this down.
I noticed a difference in the cFTP:Directory() between 2.6 and 2.5b3.
Filenames with spaces weren't being returning correctly, only the part after
the space was in the F_NAME of the array. However the Directory() in the
SDK works fine for this. So just subclass the cFTP and use the DIRECTORY()
Method out of the SDK and it works the same as 2.5b3.
Gary
Gary Stark
Gary Miller wrote:
> FYI. Hopefully this saves someone a headache as I spent some time tracking
> this down.
>
> I noticed a difference in the cFTP:Directory() between 2.6 and 2.5b3.
> Filenames with spaces weren't being returning correctly, only the part after
What you're saying is true, but it's not quite as simple as that, I'm afraid.
The methods by which you're accessing the server, and server itself, both have a
large part to play in this too.
Using the FTP classes in VO, you have two methods of accessing the remote
directory's data - either FTP mode, or HTTP mode. If you're using FTP mode then
it's all relatively clean. The servers all seem to return the data in a similar
and consistant manner. Any problems such as you're describing are easy to deal
with.
If you're using HTTP mode, then you're in a different situation altogether, and
the beach you were on with FTP mode has suddenly turned into a minefield.
The problem has nothing at all to do with VO: different servers format their
HTTP directory request results differently, and this applies not just for
different servers - IIS vs Apache - but for different versions of the same
server, like IIS4 vs IIS5 vs IIS6. Just compare a localhost directory listing on
your desktop system with, say, a public ftp host running Apache.
Remember to use the http protocol when looking at these listings, and just
comparing the one server under the two different protocols will actually begin
to illustrate the type of problems that you may encounter, btw.
http://ftp.iinet.net.au/ vs ftp://ftp.iinet.net.au/, for instance. Same
server, same data, different protocols, vastly different results.
Unfortunately, there is no easy solution for this at all. You need to look at
each of the servers (server types) that you're going to be accessing, examine
them to determine the type and version that they are (this is easy, it's in the
data that they return to you) and then write a different parsing routine for
each and every one of them.
--
g.
Gary Stark
gst...@RedbacksWeb.com
http://RedbacksWeb.com
Gary Miller
Sheesh, seems like I'm talking to myself here <g>. Whilst I don't disagree
with you, in fact I agree that accessing a server via 2 different protocols
can yield 2 different results. I simply stated that the same base Method
worked differently between 2.5b3 and 2.6. This caused me a headache as I
wrote the method in 2.5b3 and then wondered why I got different results in
2.6. I wanted to share this work-around to prevent someone from acquiring
the same headache for the same reason.
Gary Miller
Gary Stark
I simply stated that the same base Method
worked differently between 2.5b3 and 2.6. This caused me a headache as I
My point though was to highlight the fact that, if you were perhaps connecting to two different servers using the same method, you would be seeing exactly the sort of issues that you're describing. I don't know if you're accessing the same server - you've not mentioned this fact - but it may may be an issue for you to consider.
I'll even go further and say that in some circumstances, going to the same URL on more than the one occasion might not always be returning you the same data from the same physical server. With tools such as mirrors, load balancing and DNS response times/advertising, time of day and network traffic at the time, many larger and/or portal sites might route your request to a different physical box - perhapsrunning different versions of the same server - from that which had previously handled the request.
If you are in control of the server - as will often be the case - then this is not an issue, and you can code as you wish to, targetting the specific server.
But if you are not in control of it, or if you are in control but are
considering upgrading it, you would be wise to see what it does and how
it returns its data before you put it into production.
wrote the method in 2.5b3 and then wondered why I got different results in
2.6. I wanted to share this work-around to prevent someone from acquiring
the same headache for the same reason.
And I wasn't disputing that at all. I was merely adding greater
depth to your issue, which might, or might not, be of value to others.
Gary Miller
Gary Miller
Geoff Schaller
I know Mr Stark has fully misunderstood where you are going with this <g>.
Thei issue you raise has nothing to do with the calling protocol of the
server because this is an FTP request. However, my code in 2.6 works and it
was the same in 2.5 unless I replaced (fixed) the method without knowing it.
I seem to remember some issue with this early on but its the code basically
out of the SDK also. Here is my file listing access method. See if its
similar to yours:
Geoff
METHOD Directory (cFile, nFlags) CLASS GCSFtp
LOCAL pData AS _WINWIN32_FIND_DATA
LOCAL hFind AS PTR
LOCAL aRet AS ARRAY
LOCAL aTemp AS ARRAY
LOCAL nContext AS DWORD
aRet := {}
Default(@cFile, "*.*")
// UH 05/25/2000
Default(@nFlags, INTERNET_FLAG_RELOAD + INTERNET_FLAG_RESYNCHRONIZE)
IF SELF:hConnect = NULL_PTR
RETURN aRet
ENDIF
pData := MemAlloc(_sizeof(_WINWIN32_FIND_DATA) )
nContext := SELF:__GetStatusContext()
// Start enumeration and get file handle
hFind := IFXFtpFindFirstFile(SELF:hConnect, cFile, pData, nFlags,
nContext)
IF hFind = NULL_PTR
SELF:LastError := GetLastError()
ELSE
SELF:__SetStatus(hFind)
DO WHILE hFind != NULL_PTR
aTemp := __GetFileData(pData)
AAdd(aRet, aTemp)
IF !IFXInternetFindNextFile(hFind, pData)
SELF:LastError := GetLastError()
IF SELF:LastError = ERROR_NO_MORE_FILES
SELF:LastError := 0
ENDIF
InternetCloseHandle(hFind)
SELF:__DelStatus(hFind)
hFind := NULL_PTR
ENDIF
ENDDO
ENDIF
MemFree(pData)
RETURN aRet
Gary Stark
Gary Miller wrote:
GaryGood points to consider. I am accessing the same server using the exact same code even accessing the server in 2.5b3 and 2.6 within minutes of each other and got the different results. But as you mention I could be accessing different servers running different software even within minutes of each other. For now, I'm happy as my code is working the way I expect it to.
Gary Miller
Ok, great. That it's now working for you is the main thing.
The results from different servers bit had me stumped for a while, because you don't, in looking at these things through your browser, even consider that the data is laid out differently. You just kind of know that you're seeing what you expect to see and carry on regardless.
When you have a application that needs to parse and process the data however, and when it's seeing a date when it expects a filename, and an EOL when it wants a date, things start to get messed up a bit. <g>
I can tell you that I have submitted this issue to bugshunter, but my gut feeling is that there's very little that Brian and whomever can do about it.
At which point do you accommodate, within the development tool, provisioning for different servers, and different versions of those same servers? And when you understand that IIS4 returns a different layout than IIS5, which in turn is different from IIS6, you can see that it's not just difficult to allow for, but you also need to consider how they might address the not released IIS7, 8, 9 ...
My personal view is that this is something that we need to be aware of and understand, and then deal with on a case by case basis.
I also don't know, but perhaps as individuals develop server speciific
extensions to the cFTP class, they could be added to a specific library
on KnowVO or CAVO.com ?
Gary Miller
Well, you're using the method out of the SDK you're ok then because this
worked fine in my tests. From what I can tell, standard 2.6 behavior
didn't follow the SDK though.
Gary Miller
Gary Stark
Geoff Schaller wrote:
> Gary,
>
> I know Mr Stark has fully misunderstood where you are going with this <g>.
In fact, you may be correct. The stuff I was referring to was actually based on
some work I was doing recently that started with the FTP sample of Uwe's but
which caused problems when you selected the HTTP protocol to move the data via
FTP rather than using the FTP protocol. Thei issue you raise has nothing to do
with the calling protocol of the
> server because this is an FTP request. However, my code in 2.6 works and it
Note though that this is a client-side selection, not a server side one. The
client will request the data from a server using a particular protocol; the
server knows nothing of the request until after the event, and it will respond
only as per the requests made of it.
In Gary's case, yes, you're correct, and I was off on a related but signifcant
issue, albeit one that Gary and I had already agreed is not actually what Gary
was seeing.
But simply saying that it's FTP isn't quite the full answer, because the
server's responses do come into play.
I strongly suggest grabbing Uwe's original FTP sample, where you'll see that you
can, using FTP but then checking the HTTP box, use the HTTP protocol/server to
access FTP sites. Perfectly reasonable and legal, but the fun starts when you
start accessing a few different FTP sites running different HTTP servers. Try
the one I mentioned earlier, and compare the output that you're seeing with that
from an IIS server, and you'll some pretty strange things ....
Geoff Schaller
to make it properly useful.
I know it was OT to the original question but what perhaps was interesting
in your reply is the possibility to execute ftp via http (ie as per via the
usual web browser). Perhaps we should investigate the code necessary and add
it to the HTTP class in VO? It only requires a URL and sometimes a login???
Geoff
Gary Stark
Geoff Schaller wrote:
> Yes... ok, but the FTP server checkbox doesn't work in enough circumstances
> to make it properly useful.
Actually, it does work in all circumstances that I've seen, but the parsing of
the data returned is inconsistent because of the fact that there's no
consistency in how the http servers format the ftp data that they send back.
And that is where the real problem arises - each server that you wish to support
needs to have a custom parsing routine written to deal with its unique
formatting and layout. At which point do we accept that we have enough servers
catered for? Who decides which ones they might be?
Consider too the servers - IIS 6 and IIS 7, Apache 4, etc that are not yet
completed/written. I've not even considered O'Reilly's or Netscape's, and
there's still more than a few others too.
My earlier suggestion was that perhaps we should start to build a public archive
of these, so that as you or I, or whomever else builds the parser, we add that
parser to the collective knowledgbase for all to use. The parser is simply a new
method of dealing with what is essentially the same sort of data. Oh for real
polymorphism ... :)
I think that KnowVO/CAVO.com would be the logical places for these to live.
> I know it was OT to the original question but what perhaps was interesting
> in your reply is the possibility to execute ftp via http (ie as per via the
> usual web browser).
Exactly, but moreover you can do that programatically, and given that you're
looking at a website, the issues of authentication can be bypassed. I do ... :)
> Perhaps we should investigate the code necessary and add
> it to the HTTP class in VO? It only requires a URL and sometimes a login???
Not even.
Geoff Schaller
parsing of
> the data returned is inconsistent because of the fact that there's no
> consistency in how the http servers format the ftp data that they send
back.
Ok... then yes I agree
> My earlier suggestion was that perhaps we should start to build a public
archive
> of these, so that as you or I, or whomever else builds the parser, we add
that
Ok also... when time permits.... <g>
ilias
wrote:
>FYI. Hopefully this saves someone a headache as I spent some time tracking
>this down.
Hopefully everyone would publish detected bugs and solutions this way.
>
>I noticed a difference in the cFTP:Directory() between 2.6 and 2.5b3.
>Filenames with spaces weren't being returning correctly, only the part after
>the space was in the F_NAME of the array. However the Directory() in the
>SDK works fine for this. So just subclass the cFTP and use the DIRECTORY()
>Method out of the SDK and it works the same as 2.5b3.
Finally it looks, that the repository was never out of sync before
VO2.6.
It looks that GrafX's source-code 'experiments' bring the repository
out-of-sync.
-
Additionally: The above problem with cFTP:Directory() is one of the
many nice examples for this statements:
"
[...]
Major library-code-cleanups can critically influence stability of
existing applications (problems when migrating VO26-sources to VO27).
There are already [possibly unnecessary] problems when migrating
VO25-sources to VO26.
[...]
"
http://groups.google.com/groups?selm=6b8vjvks1m0kbfeu4...@4ax.com
-
>
>
>Gary
>
>
>