aFiledelete limitation

[smarr]

Is there a limitation calling this function, it appears that after 32766 execution in the same code, the application is crashing
Here is the code and attached are the traces :

debugTrace(10, "c:\temp\tracewbt_Init.txt")
dir = "d:\temp\filit\"
dirchange(dir)

AddExtender("wwsop34i.dll",0,"wwsop64i.dll")
:E10

wfiles = fileinfotoarray("*.*", 1)
xx = wfiles[0, 0]
for k = 1 to 34000
   ftd   = wfiles[k, 0] 
   afiledelete(ftd, 1028)
   if k == 1
      debugtrace(@off)
   else
      if k == 32700 then debugTrace(10, "c:\temp\tracewbt_End.txt")
   endif
next

[td]

You are going to have to offer more details by saying exactly what you mean by 'crashing'.  The trace files provide very little that is useful.  I think the administrator of this forum should add the word 'crash' and its derivatives to the forum's band word list as they can have too many different meanings in the context of the forum and are often used in place of an informative explanation of a problem.

It is also unclear why you are calling the function  32766  times since it would appear that the same result can be achieved by calling the function once. 

There are no known 'limitations' on the number of times the function can be called.  However, the extender function is a relatively thin cover for an underlying Windows Shell API function and MSFT may have some undocumented limitations or bug in their API.

[smarr]

In this case, crashing means that I got a Windows popup saying the application stops working, it tries to find a reason for the crash, find nothing and close the program with a 255 return code.
Looking into to the tracewbt_end.txt you may find that I am not excuting 32766 time the same action, I am deleting one by one all files located in a folder (> 279000)

[td]

In this case, crashing means that I got a Windows popup saying the application stops working, it tries to find a reason for the crash, find nothing and close the program with a 255 return code.

Much better thank you.

Looking into to the tracewbt_end.txt you may find that I am not excuting 32766 time the same action, I am deleting one by one all files located in a folder (> 279000)

Perhaps I should have stated it more clearly but I think you missed the point.  If you check the extender's help file documentation, you will discover that the aFileDelete function takes wildcards so you can delete all the file in a folder with a single call to aFileDelete.

[smarr]

Yes, I know, of course in the  small demo I sent you, I could use wildcards. In the real code, more complex, I have to do a file by file test in order to determine if I have to delete it or not. (Base on file creation, access, or modification date : older than a date value).
Btw, if you have piece of code (WMI, ..) that will help to get directly the right file list, based on of  these date test, it would be great.

[stanl]

FileTimeGetEx() -

I have an older WMI example, I can check in my archives, but I think the above WB function would be easier.

[smarr]

Thanks, yes I use this function in order to qualify  or not the file for deletion.
I was looking for something
SELECT * from Cim_DataFile where path = "\\Users\\name\\*.txt" and Drive="C:" and last_acess < "2015:01:01:00:00:00" or others syntax

[td]

As it turns out we were able to identify a problem in the Shell Operations extender that was very likely the cause of your aFileDelete limitation error.  Interestingly enough this problem has been around for 15 years and no one has brought it to our attention before.

An updated extender has been posted to the Download page and thanks for providing the information necessary to identify a problem.

[kdmoyers]

Whoa, smarr, nice get!!
(finding an actual bug is a rare and wonderful thing)
-Kirby

[smarr]

Thanks, difficult to isolate because the loop contains also call to function/subroutine and I first thought to them. Thanks to WB team for their reactivity