AutoIt Version Differences ..?

[Anteaus]

... or my sloppy coding? Don't think so, though.

Have quite a number of scripts originally compiled with Aut2Exe 3.1.1.0. These scripts are mostly concerned with file-copying, backup, management of network drive-mappings, etc.

Been trying to update them for use with the latest Aut2EXE, but have hit an ongoing series of snags. Some of these are documented differences in function-behaviour, but others are not so easily explained.

One I'm wrestling with just now is that the FileFindFirstFile().. FileFindNextFile() function-pair in 3.2.8.0 appear to return an entirely different fileset from that returned in 3.1.1.0

I originally though the problem was in my code, but a test shows that it can't be; even a very simple script to write a recursive directory-listing to a file shows a major discrepancy in the number of files and folders when compiled with the two versions.

A test with 3.2.2.0 shows the same behaviour as 3.2.8.0 suggesting the change in behaviour came before this. Only, the 3.1.1.0 behaviour gives a correct result for the number of files in a folder, the latter incorrect, so this is clearly not a bug-fix change as such.

I'm aware that later versions don't list the . and .. files, BTW. I originally thought that was the issue, but no. The discrepancy is far too large, and remains even if these are filtered from the 3.1.1.0 output.

AFAIK neither of these functions takes any arguments save the filespec, so it can't be the way I'm using them.

Tested in Server 2003, XP SP2, and Win95B. With the same test data, all display the same discrepancies, so for once we can't blame Microsoft either!

Can anyone shed any light? Been trying to track this one down since 2pm today and I'm about ready to give up and head t'a pub.

[PsaltyDS]

Please post example code that can be run under the various versions to see your symptoms.

[Anteaus]

Please post example code that can be run under the various versions to see your symptoms.

At the moment I'm not sure which part of the code the problem is in. I did knock-up an example but it failed to demonstrate the problem, leading me to suspect the problem isn't with FileFind itself.

I'm beginning to think it might be something to do with identifying directories for processing. Reason I think this is that a nonrecursive loop doesn't show the problem, whereas a recursive one lists the toplevel directory OK, but then fails to process some subdirs. Why some and not others I don't know, can only assume it's an attribute issue. Or, maybe to do with wildcard processing. At the moment, not sure.

If I can narrow it down I'll post an example.

[Anteaus]

Found the problem.

In 3.1x, FileFindFirstFile() returns @error=1 if the expression contains an error, such as an invalid search-path.

In 3.2x, FileFindFirstFile() returns @error=1 if the expression contains an error, OR if the directory exists but contains no files.

I had included a trap in the program that would abort the scanning of a directory if an error occurred. (Which seemed wise at the time...) In 3.2.x the trap was being false-triggered by this change in behaviour.

Edited February 24, 2008 by Anteaus

[MHz]

In 3.1x, FileFindFirstFile() returns @error=1 if the expression contains an error, such as an invalid search-path.

In 3.2x, FileFindFirstFile() returns @error=1 if the expression contains an error, OR if the directory exists but contains no files.

Not sure where your getting your information from as I will quote from the helpfiles.

Success: Returns a search "handle" or use with subsequent FileFindNextFile functions.

Failure: Returns -1 if error occurs.

No @error macro mentioned. You test the return value for -1 as being an error condition of not getting a handle.

Success: Returns a search "handle" for use with subsequent FileFindNextFile functions.

Failure: Returns -1 if error occurs. If the Folder is empty the @error is set to 1.

@error macro is mentioned. You test the return value for -1 as being an error condition of not getting a handle. You can optionally test the @error macro for the detection of an empty folder if you considered it worthwhile.

This is different to your interpretation

[Anteaus]

This is different to your interpretation

Don't see how it is.

My understanding:

FileFindFirstFile() : Set the search-path for a directory operation.

$handle = FileFindFirstFile("C;/Windows\*.*")

3.1: Returns @error=True

3.2: Returns @error=True

Which is a correct response, because the command cannot be carried-out.

DirCreate ( "C:\Empty" )

$handle = FileFindFirstFile("C:\Empty\*.*")

3.1: Returns a normal response.

-Which is correct behaviour. The directory exists and the search-path is valid.

3.2: Returns @error=True

-Which seems to indicate an error in the search-path.. but there is none, it is valid.

FileFindNextFile() : Get the next file in the search-path.

$file= FileFindNextFile($handle)

3.1: Returns @error=True

3.2: Returns @error=True

Which is correct behaviour, as the command cannot be carried-out if the list of files has been exhausted,or is null.

[MHz]

...

$file= FileFindFirstFile($handle)

3.1: Returns @error=True

3.2: Returns @error=True

Success: Returns a search "handle" or use with subsequent FileFindNextFile functions.

Failure: Returns -1 if error occurs.

How can you get @error macro set when it is not mentioned as being in the helpfile in AutoIt v3.1.1.0. Your code appears to be flawed.

Edit:

FileFindFirstFile is the focus. So is filefindnextfile the concern now?

Corrected the quote to FileFindFirstFile

Edited February 24, 2008 by MHz

[therks]

According to the help file as quoted by MHz, @error is not set for any purpose in v3.1. Just because it is returning a value does not mean it should be used. If it is not documented, it is not reliable. As the help file says (for 3.2), @error is only supposed to be set when the folder is empty. In each of your test situations, have you checked the result of $handle? I would wager that for your first example it is -1, and for your second example it is a positive integer (a valid handle for FileFindNextFile).

*Edit: Oops, beaten to the punch.

Edited February 24, 2008 by Saunders

[Anteaus]

I think this whole thread is degenerating into nit-picking. The whole point is that the change in behaviour creates a situation where an error-check (which should be performed as a part of good coding-practice) gives an anomalous result, causing the routine to bomb-out when no error-condition exists.

In any case I'd ask for this difference in behaviour to be added to the changelog. It's significant enough to warrant it.

However, I just tested the routine with modifications to allow for the new behaviour.. and there are still issues with files being skipped in 3.2.8.1. So, While this is relevant it's seemingly not the root of the trouble.

Edited February 24, 2008 by Anteaus

[PsaltyDS]

I'd ask for this difference in behaviour to be added to the changelog. It's significant enough to warrant it.

What's more, I just tested the routine with modifications to allow for the new behaviour.. and there are still issues with files being skipped in 3.2.8.1. So, there must be some other difference(s) too.

You found, through trial and @error evidently (pun intended), that @error gets set in some undocumented fashion by FileFindFirstFile() in 3.1.x. Now that a legitimate documented behavior for @error has been applied, you want your imaginary interpretation supported in the change log...?

What about the fact that FileFindNextFile() sets the @extended flag if run in a week that contains a full moon? I sure hope they tell us if that gets changed! It would trash all backward compatibility with psychically determined function syntax!

[sarcasm]

P.S. If you want more action on this, post it to the BugTrac and be sure to PM Valik about it. He'll hook you up with just what you need...

[/sarcasm]

Edited February 24, 2008 by PsaltyDS

[Jos]

Don't see how it is.

My understanding:

FileFindFirstFile() : Set the search-path for a directory operation.

$handle = FileFindFirstFile("C;/Windows\*.*")

3.1: Returns @error=True

3.2: Returns @error=True

Which is a correct response, because the command cannot be carried-out.

DirCreate ( "C:\Empty" )

$handle = FileFindFirstFile("C:\Empty\*.*")

3.1: Returns a normal response.

-Which is correct behaviour. The directory exists and the search-path is valid.

3.2: Returns @error=True

-Which seems to indicate an error in the search-path.. but there is none, it is valid.

FileFindNextFile() : Get the next file in the search-path.

$file= FileFindNextFile($handle)

3.1: Returns @error=True

3.2: Returns @error=True

Which is correct behaviour, as the command cannot be carried-out if the list of files has been exhausted,or is null.

It could be me but I don't see the issue. The helpfile clearly states that the @error is set to 1 when the directory is empty and the return value is -1.

What would it buy you when the return value is set to a proper handle on an Empty directory since all you want with these functions is to find entries inside a directory ?

Jos

[Anteaus]

PsaltyDS - Firstly I try not to be abusive to other forum-members, since the number of posts (And flashiness of avatar!) may bear no relation to the poster's experience-level. As I said in my first post, it may well be that I have made a mistake somewhere in the ~200 lines of code in this library function. That is distinctly possible. I am not, after all, infallible.

You would do well to do likewise.

-and, while I could post the entire function if you like, I somehow doubt you would want to work your way through it. Hence, I don't have a simple example to post, at least not as yet.

As to the 'flaming' I got over the apparently undocumented use of @error, in fact I had used the return-value in the final version of the 3.1 code, and this displays the same behaviour. So, it is not an issue of using undocumented features.

A Question: If FileFindFirstFile() returns an error whether a directory is empty or there is an incorrect search-path, how does one write a recursive routine that will properly detect errors in its input? Maybe it's obvious and I'm missing it, but at the moment I can't see an answer to this -Other than perhaps testing each path separately before use, with FileExists() or suchlike.

Think I'd also have to say that despite Autoit being a good product, this is one of the most antisocial forums I've ever encountered. Why the hell in blazes do people have to behave like this? What is to be gained by calling everyone with a low post-count a twat? Does it occur to you that people with low post-counts maybe don't post too often because they don't often need to...?

[Jos]

A Question: If FileFindFirstFile() returns an error whether a directory is empty or there is an incorrect search-path, how does one write a recursive routine that will properly detect errors in its input? Maybe it's obvious and I'm missing it, but at the moment I can't see an answer to this -Other than perhaps testing each path separately before use, with FileExists() or suchlike.

Why doesn't testing for just the returned value of FileFindFirst() work for you ?

Think I'd also have to say that despite Autoit being a good product, this is one of the most antisocial forums I've ever encountered. Why the hell in blazes do people have to behave like this? What is to be gained by calling everyone with a low post-count a twat? Does it occur to you that people with low post-counts maybe don't post too often because they don't often need to...?

Excuse me ? is having a discussion and people not agreeing with you the same as being called a twat?

[Richard Robertson]

Did you ever think that the error value you were getting was leftover from a function that actually did make a change to it? I think that if the function made a change to the macro, it would have been documented in some way.

[Anteaus]

Did you ever think that the error value you were getting was leftover from a function that actually did make a change to it?.

Do, please read the post properly. I said that the original v3.1 program used the return value. It did not use the undocumented @error value. Someone else latched-onto the fact that I used @error instread of the return-value in an example to demonstrate the problem. This was an oversight. But, it was just a bad example, and not in any way related to the problem.

Though, which is used makes no odds to the issue here. The return value shows the same behaviour.

V3.1

Set search path to empty but valid directory: Returns $handle. (Logical)

Test for -1: Path valid, recursion working correctly, so continue executuion.

Ask for a filename; Error. (Correct behaviour)*

Abandon this search and start next.

* Not quite the whole story as 3.1 will return "." and ".." before erroring-out, but still..

V3.2

Set search path to empty but valid directory: Returns -1 (Illogical, and not consistent behaviour)

; Test for -1: Bug-out on first empty dir in tree, with an apparent recursion fault.

Ask for a filename; Error. (Correct behaviour)

Abandon this search and start next.

Edited February 24, 2008 by Anteaus

[Jos]

Guess you don't appreciate my input here since I have been ignored for the second time in this thread.

Anyways ... My last try here and maybe this time I get your attention.

This remark is BullShit:

; Test for -1: Bug-out on first empty dir in tree, with an apparent recursion fault.

Show us your code because you obviously have a issue in your code.

Edited February 25, 2008 by Jos

[therks]

*Edit: I made a super dumb mistake that MHz totally pointed out. I fixed the post to work properly. See the MHz post's quote for my original post.

I just did the following:

Created a new folder at C:\EmptyTest

Then I ran this code:

$handle = FileFindFirstFile('C:\EmptyTest\*.*')
$error = @error
ConsoleWrite('Handle: ' & $handle & @CRLF)
ConsoleWrite('Error: ' & $error)

I got:

Handle: -1
Error: 1

If I put a file in the folder I get:

Handle: 1
Error: 0

This would appear to be wrong though because shouldn't the first result be 1 and 1? I thought it would only return -1 (for handle) if the folder was invalid.

Edited February 26, 2008 by Saunders

[MHz]

$handle = FileFindFirstFile('C:\EmptyTest\*.*')
$error = @error
ConsoleWrite('Handle: ' & $handle & @CRLF)
ConsoleWrite('Error: ' & @error)

I got:

Handle: -1
Error: 0

Is that correct? If I put a file in the folder I get:

Handle: 1
Error: 0

This would appear to be a bug.

That is nice but @error is reset when you check it. You need to show the variable $error where you saved the value of @error.

[therks]

Errr oops. That was supposed to be a $ not an @. Now I feel dumb. Post corrected. Still don't think it's right though.