DirSizeCalc 2.22 (content plugin)

[icfu]

I couldn't reproduce this so far. Does it fail to work in all cases or just occasionally?

I'd say that it occasionally works but way more often fails, try background calculation. The directories are locked by totalcmd.exe. TC asks "directory isn't empty, delete anyway?" although the directory is definetely empty.

I'm not sure if I understood this correctly. Can you give an example?

I don't see any thousand separator at all, neither on directories, nor on files, besides within archives.

Are you using one of the "not follow reparse points" options?

I had tested with Top 0, Sub 0, but my standard settings are Top 3, Sub 0.
With Top 3, Sub 0 I get a calculated size on the directory with junctions only, but a "0" with the old plugin. Has Top and Sub been switched? I need a break.

Anyway, even if "No Files" is of course a very true statement when there are no files, its psychological message includes "nothing of importance, only empty directories", so I would prefer to NOT read that string when a junction is contained within.

I'm not sure if this would be an improvement. What do other testers think?

It would only be consistent. In English you also don't call them "packed" but compressed. With "packed" I associate archives.

Can you explain this a bit more?

I thought about what abbreviations also include a symbolic meaning. X is the unknown variable in mathematics, which is the origin for other connotations like "the unknown", cancelling a document with a cross or marking it as a secret, the X-files, or not available, like in IE a not available pic.

Ansi filenames are nothing special.

I understand the reason for displaying U, but I thought about it as an alternative to "Unicode Access" plugin from Alextp, only for informational purposes. Of course a non existing U means Ansi, but it should have a symbol which is hidden by default as well, at least that would be a "nice-to-have".

Icfu

[Lefteous]

2icfu

I'd say that it occasionally works but way more often fails, try background calculation. The directories are locked by totalcmd.exe. TC asks "directory isn't empty, delete anyway?" although the directory is definetely empty.

Do you mean the problems exists with all background fields or just some? If some fields which of them ?

I don't see any thousand separator at all, neither on directories, nor on files, besides within archives.

Which unit do you use?

Anyway, even if "No Files" is of course a very true statement when there are no files, its psychological message includes "nothing of importance, only empty directories", so I would prefer to NOT read that string when a junction is contained within.

The idea to show "no files" or "empty" is indeed to indicate that the directory contains nothing important. If there is any skipped file or directory for any of the possible reasons "no files" or "empty" shouldn't be displayed.

On not following reparse points:
Don't test this too much. I haven't tested this a lot with this version and still working on a simplification of this setting. I suggest to test this more in the next beta version.

It would only be consistent. In English you also don't call them "packed" but compressed. With "packed" I associate archives.

OK

I thought about what abbreviations also include a symbolic meaning. X is the unknown variable in mathematics, which is the origin for other connotations like "the unknown", cancelling a document with a cross or marking it as a secret, the X-files, or not available, like in IE a not available pic.

I'm still not sure if this is really what I want to express. Maybe I'll try johnfredcs suggestion to show an exclamation mark. In addition I could also show the error number. which is of course only helpful for me.

I understand the reason for displaying U, but I thought about it as an alternative to "Unicode Access" plugin from Alextp, only for informational purposes.

No it's really just to show the user that there is an unreadable file or directory name and because of this no file size could be retrieved.
Of course this problem will be solved in future Unicode versions of this plug-in.

[icfu]

Which unit do you use?

I am using this one, haven't tried the others with new plugin:

Code: Select all

[=dirsizecalc.Size (Background).bytes

Maybe I'll try johnfredcs suggestion to show an exclamation mark.

Exclamation mark is the widely known symbol for "attention", so it is a perfect replacement for "F": Watch out, not followed!
Have to think more about that...

In addition I could also show the error number. which is of course only helpful for me.

Not sure if it's a good idea to show an error code just because a directory cannot be accessed. Of course, for your "E" it's ok to show them.

More testing tomorrow or so, football is waiting.

Icfu

[petermad]

[=dirsizecalc.Size (Background).Mbytes] and [=dirsizecalc.Size (Background).GBytes] only seems to work for files - they always show 0 for dirs.

[=dirsizecalc.Size (Background).bkM], [=dirsizecalc.Size (Background).bkM2], [=dirsizecalc.Size (Background).bkMG] and [=dirsizecalc.Size (Background).bkMG2] ALL show the size in bytes.

[=dirsizecalc.Size (Background).kbytes] show some sizes in megabytes and some in kilobytes. for example are both 5351493 bytes and 5318 bytes shown as 5!

Most sizes are shown without thousand separator except for KB and perhaps All-Dims (I dont have a dir with > 100 BG to test that).

All these things worked in beta2.

[Lefteous]

2icfu

I am using this one, haven't tried the others with new plugin:
Code:
[=dirsizecalc.Size (Background).bytes

OK I think I know what the reaons is.

Not sure if it's a good idea to show an error code just because a directory cannot be accessed. Of course, for your "E" it's ok to show them.

I ment just for "unhandled" errors not for "access denied". In additional wouldn't help as access denied cannot be more specific.

2petermad
Thanks for testing!

[=dirsizecalc.Size (Background).Mbytes] and [=dirsizecalc.Size (Background).GBytes] only seems to work for files - they always show 0 for dirs.

Some hwo the last displayed column doesn't seem to work but only if there is more than one. Can you confirm that?

[=dirsizecalc.Size (Background).bkM], [=dirsizecalc.Size (Background).bkM2], [=dirsizecalc.Size (Background).bkMG] and [=dirsizecalc.Size (Background).bkMG2] ALL show the size in bytes.

I'm not responsible for these units. They are provided by TC.

[=dirsizecalc.Size (Background).kbytes] show some sizes in megabytes and some in kilobytes. for example are both 5351493 bytes and 5318 bytes shown as 5!

I cannot confirm this. I couldn't find a difference compared to tc.Size.kbyte.

Most sizes are shown without thousand separator except for KB and perhaps All-Dims (I dont have a dir with > 100 BG to test that)

The reason is that I use custom formats even for the standard units but forgot to apply a proper format.

[petermad]

Some hwo the last displayed column doesn't seem to work but only if there is more than one. Can you confirm that?

They are not the last columns they are kind of in the middle - see: http://madsenworld.dk/tcmd/dirsizec1.png and http://madsenworld.dk/tcmd/dirsizec1a.png (beta2)

[=dirsizecalc.Size (Background).bkM], [=dirsizecalc.Size (Background).bkM2], [=dirsizecalc.Size (Background).bkMG] and [=dirsizecalc.Size (Background).bkMG2] ALL show the size in bytes.

I'm not responsible for these units. They are provided by TC.

Well, they display differently with beta3 ( http://madsenworld.dk/tcmd/dirsizec2.png ) and beta2 ( http://madsenworld.dk/tcmd/dirsizec2a.png ) - I have only shanged the plugin between the two screenshots - nothing else.

[=dirsizecalc.Size (Background).kbytes] show some sizes in megabytes and some in kilobytes. for example are both 5351493 bytes and 5318 bytes shown as 5!

I cannot confirm this. I couldn't find a difference compared to tc.Size.kbyte.

Look at the size of the folder "Thumbs" and the file "treeinfo.wc" under the column "Size (kbytes)" in this screenshot:
http://madsenworld.dk/tcmd/dirsizec1.png they both show "5"

[abraham]

Thanks for this nice plugin. I haven't tried v2 yet but have a feature request.

Is it possible to be able to specify the maximum number of significant digits in the display? Similar to how Windows Explorer works which seems to have no more than 3 significant digits but with a variable number of decimal places. For example (using dot as decimal separator)

127b
1.27k
12.7k
127k
1.27M etc

instead of

127b
1.3k
12.7k
127.2k
1.3M etc

where you have fixed number of decimal places but variable number of significant digits.

I think it would look nicer and 3 significant digits is usually enough information.


thanks

[Lefteous]

2petermad

They are not the last columns they are kind of in the middle

OK more precise the last column not containing fields with custom units.

Well, they display differently with beta3

You don't have to post screenshots. I'm sure that your reports are true but that doesn't mean it's a plug-in problem. Maybe I'm just doing something that TC doesn't support. I'll have to look a bit deeper in the plug-in SDK to find out if TC should support what I'm doing or not.

Look at the size of the folder "Thumbs" and the file "treeinfo.wc" under the column "Size (kbytes)" in this screenshot: http://madsenworld.dk/tcmd/dirsizec1.png they both show "5"

How does the screenshot help me to reproduce the problem?

2abraham

I haven't tried v2

Version 2 is far from final and just for testers. DirSizeCalc 1.21 is the current stabel version which should be used.

Is it possible to be able to specify the maximum number of significant digits in the display? Similar to how Windows Explorer works which seems to have no more than 3 significant digits but with a variable number of decimal places. For example (using dot as decimal separator)
I will try to add it.

[petermad]

How does the screenshot help me to reproduce the problem?

It can give you the clue to make a folder containing approximately 5 Mb and a file containing 5 Kb and then try for yourself what's happening.

[Lefteous]

2petermad

It can give you the clue to make a folder containing approximately 5 Mb and a file containing 5 Kb and then try for yourself what's happening.

Don't worry I already understood your original report


It's currently quite confusing to have integrated units(byte, kbyte, Mbyte and Gbyte), some custom units and automatically generated units by TC. They behave and look quite different. There should only be one kind of units. I thought about making them all customizable but provide useful defaults.
What do you think?

[Lefteous]

Here is a new beta version of DirSizeCalc.

List of changes in Version 2.00 BETA 4:

• FIXED Options in [General] section weren't added to default ini file.
• FIXED In some cases directories could no longer be deleted if the field "Empty" or "Contains Subdirectories" were used.
• FIXED Some fields didn't display a thousand separator.
• FIXED Not following reparse point didn't show "F" when reparse points was in a subdirectory.
• CHANGED German translation: Changed "Gepackte Größe" into "Komprimierte Größe".
• FIXED The field "Contains files" didn't work at all.
• FIXED Wrong string used for not following reparse points.
• CHANGED Size display type (class, binary or decimal) is used for all size field units not just for user-defined fields.
• CHANGED Renamed default units to drop support for auto-generated TC units and to reflect size display types.
• FIXED Size display type was always classic.
• CHANGED Removed custom units from default ini file (name conflicts).
• FIXED Various fixes in the language file.

Download DirSizeCalc 2.00 BETA 4 (Totalcmd.net Server)

Download DirSizeCalc 2.00 BETA 4 (my own website)

[petermad]

The plugin reacts to thanges to [CustomUnitConfig_All_Dims] in DirSizeCalc.ini, but if I make sektions like [CustomUnitConfig_kB], [CustomUnitConfig_MB] or [CustomUnitConfig_GB] nothing seems to happen to fields with the corresponding sizes.

[Lefteous]

2petermad

The plugin reacts to thanges to [CustomUnitConfig_All_Dims] in DirSizeCalc.ini, but if I make sektions like [CustomUnitConfig_kB], [CustomUnitConfig_MB] or [CustomUnitConfig_GB] nothing seems to happen to fields with the corresponding sizes.

Please have a look a the list of changes:

CHANGED Renamed default units to drop support for auto-generated TC units and to reflect size display types.

CHANGED Removed custom units from default ini file (name conflicts).

The new standard units are B, kB, MB and GB (B, KiB, MiB and GiB when using binary display type). The custom units you list have the same name.
I will probably dynamically rename a section if such a conflict occurs in future versions.

[petermad]

Aha, I thought I could also change the settings for the standard units (like setting NumberOfDigits) - my mistake, sorry

It works fine with units with custom names

[Lefteous]

Aha, I thought I could also change the settings for the standard units (like setting NumberOfDigits)

I probably will add support for changing the standard units later. In the current version I tried to make them work just like the built-in units.