Main Area and Open Discussion > General Software Discussion
FolderSize o DirectorySize with rules or filters
rjbull:
I attach a screenshot of the candidate 1.1.3.0 release. You can notice 4 new features over the many other features added):
1. Filter by folder name (here it's not shown but also negative filters are supported). After playing a bit with this feature i can say that it's cool.
2. Notice that the folders that match the folder filter pattern are displayed with name in BOLD font. This makes easier to understand why stuff has been included by the filter.
3. I filtered also by zip and jpg files. Notice they are colored with different colors (optional) because they belong to different file classes (customizable)
-uuderzo (January 12, 2011, 06:13 PM)
--- End quote ---
I don't think I really understood the syntax before. Just to check I've got it right now, the release candidate is looking at all folders, and shows all their sizes. But, it is set to filter folders that start "program*," and within those, it considers JPG and ZIP files. SpaceSniffer's main statistics at the top of the screen now show those files in those folders only, and those are the ones where text is in bright white, and specially coloured. Other folders and files are shown with their sizes, but not considered in the main statistics.
Is that correct?
4. The selected element will drop a shadow (optional) to make it easier to visually track.
--- End quote ---
Good idea; I think that helps.
Sounds like a fair bid to be the best in this class of software :)
uuderzo:
I don't think I really understood the syntax before. Just to check I've got it right now, the release candidate is looking at all folders, and shows all their sizes. But, it is set to filter folders that start "program*," and within those, it considers JPG and ZIP files. SpaceSniffer's main statistics at the top of the screen now show those files in those folders only, and those are the ones where text is in bright white, and specially coloured. Other folders and files are shown with their sizes, but not considered in the main statistics.
Is that correct?
-rjbull (January 13, 2011, 02:49 PM)
--- End quote ---
Well... not. I think that this way it should be difficult to understand. Maybe i lacked of explanation in my previous post. In the posted example, the filter is composed of two main parts: a folder mask and two file masks.
If you consider the disk structure as a tree, the purpose of the folder mask is to cut all branches whose paths don't contain "program*" in at least one nesting level.
After the tree has been cutted down, the file mask will search for the file extensions. It's like a two dimensional filter: the first axis is the folder dimension, the second axis is the files dimension. Both are perpendicular and not directly related.
Consider this example:
root
|
+Program Files
| |
| +Data
|
+Users
| |
| +Programs
| |
| +Data
|
+Windows
| |
| +System
The previous folder mask will consider all files under "Program Files\..." and all files under "Users\Programs\..." but not other branches because they don't contain "program*".
The statistic of a folder is always the sum of the size of their direct children, hence in the screenshot you will see that the C:\ drive contains 1.7Gb of JPG or ZIP files that are stored under a program* folder (at any nesting level). Actually, the C:\ drive is 300 Gb in size (without filters).
Suppose that your disk structure contains many folders with similar names, but you don't know how many and where they are (and at which nesting level they are). Without a folder mask you must examine each branch of the disk structure to find them. With folder mask you can find every "temp" folder with a click.
I think that the semanthics is simple (perhaps only to me because i programmed the algorithm, eheh), but if you have any other interpretation please let me know. I need to understand if the behavior of SpaceSniffer is what people expects.
Thank you! Umberto
Contro:
Go to the View menu, and choose "Flat View" - there are three options, so you'll need to find the one you like.
The help is pretty good, and the support forum is here:
http://www.gpsoft.com.au/Support.html
They know a lot more than I do!
-timns (January 09, 2011, 07:25 PM)
--- End quote ---
Well. Directory Opus is too much for anyone.
A nice piece of software.
Someday not very far all the advantages of directory opus will be incorporated to last version of windows.
In the present moment I recommend this program to everyone to use everyday.
This is not my situation. So I will try with the freeware SpaceSniffer.
:P
uuderzo:
Contro, you will need to wait some other few days...
Tomorrow i changed my mind about the folder name filter. Having two different pattern match methods is pretty confusing. Now i propose another solution to the problem (more efficient).
If the pattern doesn't contain the backslash (*.jpg) the pattern matching is applied only to the file name itself. So, this will make SpaceSniffer behave exactly like the released version.
If the pattern contains che backslash (\temp) the pattern matching is extended to the whole file path (final file name included).
Example: (\temp) which doesn't contain a wildcard, is implicitly extended to (*\temp\*), so "c:\windows\temp\data\abc.txt" is found
Example: (*\temp\*.jpg) will match any jpg file under a temp folder at any nesting level (because the second * will match any char sequence, hence any folder nesting)
Example: (*\temp* ) will match any file under a temp folder or any file whose name starts by temp
The only drawback is that i lose the BOLD hilight because il will need too much CPU power to do realtime.
But... maybe working always with the full path will be limiting... I wonder if the folder pattern should be extended the the full path (file name included) or only to the path (file name excluded). I still wonder which case is the most flexible...
uuderzo:
Please forget my last post.
Release Candidate will be out soon. Only a last burst of tests.
Greetings! Umberto
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version