Nasty Directory Delete Function

[eoredson]

Find attached the directory delete function.

This is a nasty directory delete function.

It deletes a directory and all subdirectories and files.

It doesn't care what the directory is.

Erik.

[mnrvovrfc]

Now I have to go find that "man" page which kept going about Guttman and an amateur hacker being able to do an "rm -rf" on somebody else's root directory. It keeps going discussions like this one:

https://distrowatch.com/weekly.php?issue=20220912#qa

This program might not work on Windows10 for something I'm thinking about. A directory under "Common Files", since I'm into music production but I don't like crap software...

@eoredson IMO I don't think it was a good idea to post this program because of what you wrote as comment at the top of your program. You should have written a better disclaimer.

[SpriggsySpriggs]

I haven't checked but does this work in 64 bit or is this code 32 bit only as it currently stands? If it is 32 bit only then you'll need to adjust your TYPE definitions so it will work in 64.

[eoredson]

" I haven't checked but does this work in 64 bit or is this code 32 bit only as it currently stands? If it is 32 bit only then you'll need to adjust your TYPE definitions so it will work in 64."

Could you be more specific when you meant to adjust your TYPE?

Erik.

[mnrvovrfc]

" I haven't checked but does this work in 64 bit or is this code 32 bit only as it currently stands? If it is 32 bit only then you'll need to adjust your TYPE definitions so it will work in 64."

Could you be more specific when you meant to adjust your TYPE?

Erik.

On 64-bit, some the fields which are "_UNSIGNED LONG" (32-bit) might have to be changed to "_UNSIGNED _INTEGER64". That is to match the function parameters of type "_OFFSET" which are going to be 64-bit pointers. Like I've noticed from part of the code below.

Code: (Select All)

TYPE WIN32_FIND_DATAA
    dwFileAttributes AS _UNSIGNED LONG
    ftCreationTime AS FILETIME
    ftLastAccessTime AS FILETIME
    ftLastWriteTime AS FILETIME
    nFileSizeHigh AS _UNSIGNED LONG
    nFileSizeLow AS _UNSIGNED LONG
    dwReserved0 AS _UNSIGNED LONG
    dwReserved1 AS _UNSIGNED LONG
    cFileName AS STRING * MAX_PATH
    cAlternateFileName AS STRING * 14
END TYPE

' declare external libraries.
DECLARE DYNAMIC LIBRARY "kernel32"
    FUNCTION DeleteFileA% (F$)
    FUNCTION FindFirstFileA~%& (BYVAL lpFileName~%&, BYVAL lpFindFileData~%&)
    FUNCTION FindNextFileA& (BYVAL hFindFile~%&, BYVAL lpFindFileData~%&)
    FUNCTION FindClose& (BYVAL hFindFile~%&)
    FUNCTION RemoveDirectoryA% (F$)
END DECLARE

[eoredson]

I changed the _unsigned long to _unsigned _integer64 and it crashed.

From what I can tell the win32_find_dataa udt _unsigned long is 32-bit which is 4*1024^3-1

Unless you have a win64_find_dataa which would be 64-bit or 16*1024^6-1.

Erik.

[SpriggsySpriggs]

I changed the _unsigned long to _unsigned _integer64 and it crashed.

From what I can tell the win32_find_dataa udt _unsigned long is 32-bit which is 4*1024^3-1

Unless you have a win64_find_dataa which would be 64-bit or 16*1024^6-1.

Erik.

You wouldn't adjust them by making longs into integer64s but you would just add padding where necessary. I'll look at your code and see if it works in 64 bit. If not, I'll help adjust your TYPEs. I'll get back to you later on this.

EDIT: The code ended up working just fine. Sweet. Good work. It deleted the directory I gave it as well as the files within.

[mnrvovrfc]

@Spriggsy get well soon.

What I've said earlier was based on what I remembered had to be done with the open and save file dialogs in the example provided in the Wiki: a few UDT members straight out had to be turned to "_OFFSET" instead of "_UNSIGNED LONG" or something like that, to step up to 64-bit from 32-bit. Otherwise it's strange that [[DECLARE LIBRARY "kernel32"]] or alike could still work on 64-bit.

https://qb64phoenix.com/qb64wiki/index.p...ave_Dialog

[SpriggsySpriggs]

@Spriggsy get well soon. 

What I've said earlier was based on what I remembered had to be done with the open and save file dialogs in the example provided in the Wiki: a few UDT members straight out had to be turned to "_OFFSET" instead of "_UNSIGNED LONG" or something like that, to step up to 64-bit from 32-bit. Otherwise it's strange that [[DECLARE LIBRARY "kernel32"]] or alike could still work on 64-bit.

https://qb64phoenix.com/qb64wiki/index.p...ave_Dialog

Unfortunately, that code on the Wiki is very poor. I had rewritten it a while back and submitted it to the old Wiki before it got relinquished. So I'm not sure if that code is something that someone wrote over what I did or if what's there now is a copy from an older Wiki page. I can provide you with more updated Open/Save Dialog code, though.