here's the comment area for today's blog post found at
http://zabkat.com/blog/delete-with-wildcard.htm
blog: delete with wildcards
Moderators: fgagnon, nikos, Site Mods
As this method effectively works the same as a search-framework, it feels a little weird to have the mask apply to items which may not actually even be displayable (such as hidden files). That said, it can be exploited to save you the multi-step trouble of showing-hidden files, searching for desktop.ini's, selecting them all, deleting them, then hiding hidden files again.
I'm just saying it feels weird (and verges on being somewhat unexpected behaviour).
It also doesn't automatically make it clear that no items may have been deleted (if nothing matched the mask) unless you regularly remember to tick that "keep this dialog open" box, which I thought only masochists used. Are you encouraging us to become masochists? If so, I have a few other suggestions, perhaps unrelated to file-management, which I learned from a mystical Bulgarian woman (who also had this thing about how crystals should be applied during massages) which may themselves prove entertaining...
I'm just saying it feels weird (and verges on being somewhat unexpected behaviour).
It also doesn't automatically make it clear that no items may have been deleted (if nothing matched the mask) unless you regularly remember to tick that "keep this dialog open" box, which I thought only masochists used. Are you encouraging us to become masochists? If so, I have a few other suggestions, perhaps unrelated to file-management, which I learned from a mystical Bulgarian woman (who also had this thing about how crystals should be applied during massages) which may themselves prove entertaining...
Umm - the more I play with this, the less I like it. Say, for example, you have a subfolder named "desktop.inis", which is inside of another folder, and both are empty, but the folders below it contain files, a couple of which are the desktop.ini I actually do want to remove, using a mask such as "desktop.ini" will also (unexpectedly!) delete the "desktop.inis" folder, and its containing folder (which was just named "New Folder") simply because it had no other contents. That's not right. The dialog window also only shows "files" removed, it does not count "folders" unless you specifically view the log. I don't actually mind the removal of the "desktop.inis" folder, as folders are assumed to be included in a general mask (which itself assumes the "*desktop.ini*" wildcard character inclusions) and the name does match (though the log does not say it's deleted via the filter!), but its containing folder does not match anything.
As in this case, 4 objects are actually removed - but a quick glance would only say "2 files" in the dialog itself, even at the end of the log. Why not say "4 objects"?
And why is the folder named "New Folder" removed? It doesn't match the mask! It's only crime was being empty!
As in this case, 4 objects are actually removed - but a quick glance would only say "2 files" in the dialog itself, even at the end of the log. Why not say "4 objects"?
And why is the folder named "New Folder" removed? It doesn't match the mask! It's only crime was being empty!
------- 24-Feb-13 13:28:41 ------------
job #3 [Delete 1 item(s) {0023}F: C:\Etrangere\New Folder]
FILTER DETAILS
Matching items: Folders, Files
Name wildcard: desktop.ini
Deleted through filter C:\Etrangere\New Folder\desktop.ini
Deleted through filter C:\Etrangere\New Folder\New Folder\desktop.ini
deleted folder C:\Etrangere\New Folder\New Folder\New Folder\desktop.inis
deleted folder C:\Etrangere\New Folder\New Folder\New Folder
job finished, deleted 2 files
I'm going to officially class this as a bug report, as it's easily repeatable: when using a mask, any empty folder/subfolder or folder/subfolder which results in being empty due to any filter-matching files within it being removed, are themselves permanently removed, irrespective of those folder/subfolder names matching the filter. Only folders/subfolders with remaining unmatched content are preserved.
You can't claim that's by design.
You can't claim that's by design.
Last edited by Kilmatead on 2013 Feb 24, 15:56, edited 1 time in total.
first of all, if you use a filter called desktop.ini (which is automatically translated as *desktop.ini*) then its nobody's fault if you have a folder called desktop.inis and it gets the boot too: if you can't stand the heat you better stay out of the kitchen. You can use a full filter where you specify files/folders explicitly
as for the empty folder thingy, you could call it a bug or you could call it xplorer2 being smart and saving you extra work, you pick!
as for the empty folder thingy, you could call it a bug or you could call it xplorer2 being smart and saving you extra work, you pick!
I already said I disclaimed the folders named "desktop.inis" being removed as they do match the filter, so that's kosher, if dodgy (most users don't actually realise that x2 automatically adds the prefixed and suffixed "*" characters to any typed filter unless 'verbatim' tagged).
However, the Empty Folder problem is most certainly a bug - many users will keep whole structures of empty/half-empty folders as an organised table "waiting" for content to be moved into them at a later date, such as client lists. If whole swathes of these are randomly/haphazardly removed even if they don't match the filter or even if they're hidden, then that's actually damaging the existing structure the user (obviously) wished to preserve by using a filter in the first place!
You can't rationalise your way out of damaging an existing folder structure, Mr. "I'm saving work by chopping off my fingers".
However, the Empty Folder problem is most certainly a bug - many users will keep whole structures of empty/half-empty folders as an organised table "waiting" for content to be moved into them at a later date, such as client lists. If whole swathes of these are randomly/haphazardly removed even if they don't match the filter or even if they're hidden, then that's actually damaging the existing structure the user (obviously) wished to preserve by using a filter in the first place!
You can't rationalise your way out of damaging an existing folder structure, Mr. "I'm saving work by chopping off my fingers".
Actually, it's even worse - filters simply are not applied to folders at all even if they explicitly match the names! No matching folders will be removed unless they are empty! What kind of backward Communist after-school club are you running here? Who wrote this thing? Won't anyone think of the children?
(That Ballmer video isn't looking so bad after the featherless-cuckoo dictator we've got!)
(That Ballmer video isn't looking so bad after the featherless-cuckoo dictator we've got!)
This is kind of a mess. IMHO there is too much going on automatically. That may be fine for the very experienced user or the user that does a particular filter operation frequently. However for someone who might have need of this feature a few times a year, a virtual minefield awaits them.
A folder should ONLY be removed if it is empty UNLESS it is explicitly called out in the filter expression (NOT after automatically appending asterisks to both ends). Better yet, one or two checkboxes should be included to specify if folders are to be included in the operation AT ALL. That way if one wants to insure maintaining a structure (as Kilmatead suggests) they can be assured that they will. If you include 2 checkboxes (Files & Folders) checking one or the other or both will include them in the filter results. Checking NEITHER will run the filter showing matches but not actually doing anything - so the user can see what would happen before actually doing it. Here I am assuming there is a log/list of what was actually done (deleted, moved, etc.) that the user can review. As a novice, I am not aware if that functionality already exists - if so, then the “neither ticked” option would not be needed.
Again, I may be way off base here, because of my lack of knowledge and experience with X2. However I am not a newbie to using computers nor to using file managers. So please consider the functional intent of my comments (assuming their intent is clear enough to you) rather than the explicit method of their implementation.
A folder should ONLY be removed if it is empty UNLESS it is explicitly called out in the filter expression (NOT after automatically appending asterisks to both ends). Better yet, one or two checkboxes should be included to specify if folders are to be included in the operation AT ALL. That way if one wants to insure maintaining a structure (as Kilmatead suggests) they can be assured that they will. If you include 2 checkboxes (Files & Folders) checking one or the other or both will include them in the filter results. Checking NEITHER will run the filter showing matches but not actually doing anything - so the user can see what would happen before actually doing it. Here I am assuming there is a log/list of what was actually done (deleted, moved, etc.) that the user can review. As a novice, I am not aware if that functionality already exists - if so, then the “neither ticked” option would not be needed.
Again, I may be way off base here, because of my lack of knowledge and experience with X2. However I am not a newbie to using computers nor to using file managers. So please consider the functional intent of my comments (assuming their intent is clear enough to you) rather than the explicit method of their implementation.
It's not actually a mess - it's just not meant for beginners who expect user-friendliness - for that, the "traditional" means should be used.
All the functionality you refer to already exists - clicking the "Define" button next to the Filter line will open the stock filter definition dialog (such as from <Ctrl+F>, etc) which contains the checkbox options for Folders and/or Files inclusive operations (see page 405 of the PDF manual for more details of the hyperfilter dialog), as well as the far more complex rule-based-system.
Checking "Keep progress window open after the end of deletion" will (obviously) keep the window open so you can check the Log-tab, etc, as desired (such as the one I posted above) after the operations have finished.
All that may seem "hidden" to you, but effectively any of this functionality should only be considered "Advanced" (automated) - 9 times out of 10 the user would delete in the traditional way: conduct a search for the items they wish to delete then select them all/partial from the resulting scrap container, and then use <Shift+Delete> simply allowing it to do its thing, as they have already "previewed" their choices by doing it manually. Using a filter directly from the dialog is "advanced" because it skips all those other steps which (by the nature of being "steps") allows the user to quit at any time - this does not, thus it's far quicker, but more prone to mistakes as would be expected, so caveats would apply.
The telling thing here is that this filtering business has apparently been bugged for the last 3 years and 4 months - the fact that no one noticed it before now tells you how many people actually apply explicitly recursive content filters from this post-selection dialog. Commendable that Nikos wishes to drum up interest in it, but he should make sure it works as advertised before introducing the great unwashed to the concept of soap.
All the functionality you refer to already exists - clicking the "Define" button next to the Filter line will open the stock filter definition dialog (such as from <Ctrl+F>, etc) which contains the checkbox options for Folders and/or Files inclusive operations (see page 405 of the PDF manual for more details of the hyperfilter dialog), as well as the far more complex rule-based-system.
Checking "Keep progress window open after the end of deletion" will (obviously) keep the window open so you can check the Log-tab, etc, as desired (such as the one I posted above) after the operations have finished.
All that may seem "hidden" to you, but effectively any of this functionality should only be considered "Advanced" (automated) - 9 times out of 10 the user would delete in the traditional way: conduct a search for the items they wish to delete then select them all/partial from the resulting scrap container, and then use <Shift+Delete> simply allowing it to do its thing, as they have already "previewed" their choices by doing it manually. Using a filter directly from the dialog is "advanced" because it skips all those other steps which (by the nature of being "steps") allows the user to quit at any time - this does not, thus it's far quicker, but more prone to mistakes as would be expected, so caveats would apply.
The telling thing here is that this filtering business has apparently been bugged for the last 3 years and 4 months - the fact that no one noticed it before now tells you how many people actually apply explicitly recursive content filters from this post-selection dialog. Commendable that Nikos wishes to drum up interest in it, but he should make sure it works as advertised before introducing the great unwashed to the concept of soap.
Where is that "trashbin" icon found in the video ?
Hello,
Looking at the video, I wonder where to find that "trashbin" icon found on the toolbar and how to add it.
Thanks
-Pierre
Looking at the video, I wonder where to find that "trashbin" icon found on the toolbar and how to add it.
Thanks
-Pierre
