FYI:
Running my C11 program on an RDP session in an Azure production server, I found that deleting one client-side file, on a redirected drive, was taking 22 seconds!
After replacing the REMOVE(filename) with ds_DeleteFile(filename), from CapeSoft’s “WinEvent” product, it now takes less than 2 seconds!
Yes, there was a great discussion on this matter using windows api vs clarion remove
Win32_DeleteFile PROCEDURE(*CSTRING lpFileName ),BOOL,PROC,RAW,PASCAL,DLL(1),name(‘DeleteFileA’) !Win API way to Delete a File
Win32_GetLastError PROCEDURE(),LONG,PASCAL,DLL(1),NAME(‘GetLastError’)
Clarion REMOVE is Windows API’s SHFileOperation… Among other thing REMOVE supports wildcards in the passed file name, though the name should not begin with a wildcard characters^
Perhaps it could have had some logic to decide whether a call to SHFileOperation was warranted, or if the faster way could be used.
Until somebody figured out what was happening, all of a sudden everyone’s apps slowed way down when temp report files were removed. Not a nice surprise, when you have a lot of pages. It seems to the user like the app is frozen, and then they kill it.
It’s Shell’s work to decide how execute SHFileOperation optimally depending from parameters and from kinds of involved files’ locations. If it not works well in case of processing files via Remote Desktop Protocol, this is the Shell’s problem. Though SHFileOperation works good for local and networked (e.g. using SMB or NFS protocols) files.
Maybe the problem is that it takes too long to decide. Either way, a lot of devs use a “fast remove” function instead of the built-in REMOVE() because of the slowness.
A REMOVE(*QUEUE pFileQueue) would be useful. It could create a big string of filenames with the null delimiter, then call SHFileOperation one time.