I see a rather lengthy (and virtually unproductive)
discussion on the FTPFileExists command, and how it
always returns a value of TRUE, regardless whether
the file exists or not.

It was procisely because of this command that I recommended
the 24x7 program to a client (and that client just happened
to be the Internal Revenue Service). Granted, the FTPDir
command can be used instead, and produces similar results,
but the clients concern is now running along the lines of,
"Geez, what else doesn't work?"

What is your gameplan to correct this issue?
Are there any other known errors with the 4.17 release?

FTPFileExists is working fine here and in many other places. By the way, it internally uses the same FTPDir method in order to provide support for file masks.

It is something else in your environment that causes FTPFileExists to always report yes.

The main problem is that FTP protocol does not support DIR or FILE EXISTS commands. To fill the gap the system executes native DIR (Windows) or LS (Unix) command on the FTP host and then parses the output (bunch of free text) trying to extract file names, dates, sizes, etc... If the FTP host does NOT return standard file listing anything can happen. This becomes especially complicated when the listing is returned in local languages. Perhaps your client's FTP host always returns the original DIR/LS command with parameters as the first line of the file listing or returns something similar which tricks the 24x7 to recognize this string to as a valid file name.

Anyway, here is how you can troubleshoot this issue.
Find out from your client which operating system they run on the FTP server and ask them to provide output of the native DIR (or LS) command. Also ask them to run a trace on the FTP session initiated from 24x7. Compare it to results of the processing on the different FTP server and you will find what's causing the incorrect behavior.

PS. The worst case in my experience was working with HP-UX v.10. That system returned sometimes file names without extensions, file times without time portions (dates only), dates without years and so on...

: I see a rather lengthy (and virtually unproductive)
: discussion on the FTPFileExists command, and how it
: always returns a value of TRUE, regardless whether
: the file exists or not.

: It was procisely because of this command that I recommended
: the 24x7 program to a client (and that client just happened
: to be the Internal Revenue Service). Granted, the FTPDir
: command can be used instead, and produces similar results,
: but the clients concern is now running along the lines of,
: "Geez, what else doesn't work?"

: What is your gameplan to correct this issue?
: Are there any other known errors with the 4.17 release?

Well, this was a Sun e10000, running Solaris; should be as generic as they come.
We ended up using the FTPDir command, which worked,
albeit with a bit of trickery. The reponse from the FTPDir command is
"SP.SM.DISTR1542: File or directory does not exist." if the target file
dosn't exist, so we have to scan the string for the words "does not exist"
in order to determine existence of the file.

As the scripts we're building must work seemlessly across multiple
platforms, and since one of those platforms will be an IBM AS/400,
I'll substitute the FTPDir for the FTPFileExists, and forgo the issue
altogether...

Thanks for the info.

- Rick

: FTPFileExists is working fine here and in many other places. By the way, it
: internally uses the same FTPDir method in order to provide support for
: file masks.

: It is something else in your environment that causes FTPFileExists to always
: report yes.

: The main problem is that FTP protocol does not support DIR or FILE EXISTS
: commands. To fill the gap the system executes native DIR (Windows) or LS
: (Unix) command on the FTP host and then parses the output (bunch of free
: text) trying to extract file names, dates, sizes, etc... If the FTP host
: does NOT return standard file listing anything can happen. This becomes
: especially complicated when the listing is returned in local languages.
: Perhaps your client's FTP host always returns the original DIR/LS command
: with parameters as the first line of the file listing or returns something
: similar which tricks the 24x7 to recognize this string to as a valid file
: name.

: Anyway, here is how you can troubleshoot this issue.
: Find out from your client which operating system they run on the FTP server
: and ask them to provide output of the native DIR (or LS) command. Also ask
: them to run a trace on the FTP session initiated from 24x7. Compare it to
: results of the processing on the different FTP server and you will find
: what's causing the incorrect behavior.

: PS. The worst case in my experience was working with HP-UX v.10. That system
: returned sometimes file names without extensions, file times without time
: portions (dates only), dates without years and so on...

Thank you for the info.

: Well, this was a Sun e10000, running Solaris; should be as generic as they
: come.
: We ended up using the FTPDir command, which worked,
: albeit with a bit of trickery. The reponse from the FTPDir command is
: "SP.SM.DISTR1542: File or directory does not exist." if the target
: file
: dosn't exist, so we have to scan the string for the words "does not
: exist"
: in order to determine existence of the file.

: As the scripts we're building must work seemlessly across multiple
: platforms, and since one of those platforms will be an IBM AS/400,
: I'll substitute the FTPDir for the FTPFileExists, and forgo the issue
: altogether...

: Thanks for the info.

: - Rick