DeleteFiles icon indicating copy to clipboard operation
DeleteFiles copied to clipboard

filespec does not work as expected

Open ajweber opened this issue 8 years ago • 4 comments

I have a number of top-level directories that are auto-created by a piece of software that apparently has a bug, because it does not clean them up and it makes sub-folder paths that are way over MAX_PATH length. These are all named according to the following "pattern": "C:\Temp_#+" In other words, the directory is made in the root of the C-drive, it's prefixed with the word "Temp", followed by an underscore, and a number (could be any number of digits, but at least one digit).

So I tried using DeleteFiles with an absolute path/filespec as follows: DeleteFiles.exe c:\Temp_?* -r -f -l This attempts to delete files and folders that are way different than what I would expect that filespec to cover. In fact, it's very dangerously traversing into the Windows directories, User directories, etc. Please see the output from that exact syntax from my server (attached, below).

If you look at the following directory listing (using the same filespec), you'll see what I expected to get purged by the program: C:>dir c:\Temp_?* Volume in drive C is SystemDisk Volume Serial Number is 24AA-6D75

Directory of C:\

02/22/2017 08:53 AM <DIR> Temp_1234 02/22/2017 08:53 AM <DIR> Temp_34 0 File(s) 0 bytes

test.txt

ajweber avatar Feb 22 '17 14:02 ajweber

Well I think the behavior you're seeing is to be expected because you are telling DeleteFiles to look for files that start with Temp_* in the C:\ folder. The last segment is treated as a file wildcard not a folder listing wildcard. There's no way to know what your intent is here. Basically this traverses the entire drive and deletes any empty folders even those where no files where deleted.

RickStrahl avatar Feb 23 '17 00:02 RickStrahl

OK, it's your app, but that doesn't logically fit with ANY other app I have ever seen, nor is that documented.

If you're looking to supply a "root path" to the app, and a separate wildcard spec for deletion, then you should simply have two mandatory parameters (a dot being a valid first parameter). If you try the filespec I mention in any other utility I can think of (including all the defaults that come with Windows), you get dramatically different results (as evidenced by the simple "dir" command-example I supplied).

ajweber avatar Feb 23 '17 13:02 ajweber

Yeah but the Dir command doesn't do recursion so the behavior is drastically different. And as I said currently the filespec only looks at files.

But even if it looked at both files and folders it would still traverse the entire tree and remove empty folders because you specified the -f switch which removes any empty folders along the way even if they don't match the 'folder spec'. As long as it's along the path traversed the -f flag will remove empty folders which is what you typically want when you're clearing out folder structures. If that's not what you want then you shouldn't be using the -f flag.

So, I agree that perhaps it would be more natural if DF could also detect directories which would then allow you to run the command without the -f parameter that now clears all empty directories along the way to get the result you'd expect. Directories if matching the file spec would also be removed.

DeleteFiles.exe c:\Temp_?* -r  

RickStrahl avatar Feb 23 '17 22:02 RickStrahl

Not to be pedantic, but DIR /S C:\Temp_?* would actually be the dir command doing recursion and only going into folders that match the "Temp_?*" wildcard from the root directory. It would NOT go into C:\Users or C:\Windows, etc.

The use case is to delete those top level folders and anything inside them (folders or files, including long foldernames). So in my case, I'm trying to specify a dirspec, not a filespec...maybe that's where things are going astray.

Anyway, thanks again!

ajweber avatar Feb 23 '17 22:02 ajweber