search

andrewhayden / folderslice

Automatically exported from code.google.com/p/folderslice
0 stars 0 forks source link

Stats for directory incorrect #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Dropped entire C: drive 
2. Dropped single folder
3.

What is the expected output? What do you see instead?
Folder C:\temp contains two sub directories
Moto (stats appear to be correct)
Notes Data (stat incorrect) 126.6% -8662231445 bytes 1627 files 

What version of the product are you using? On what operating system?
Ver 0.9.3

Vista Ultimate with SP1 Beta Build 6001

Please provide any additional information below.
I dragged the Notes folder only and still same problem stats.

Original issue reported on code.google.com by gregs...@gmail.com on 9 Dec 2007 at 3:34

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the report, and the diagnostic information.  I will look into this.

Original comment by andrew.h...@gmail.com on 9 Dec 2007 at 7:22

GoogleCodeExporter commented 9 years ago 
Ah, this seems like a rookie mistake on my part.  The size of the Notes folder 
you
have on your hard drive is 7,727,865,581, or about 7.5 GB.  The gadget is 
seemingly
using 32-bit integers to store the size, which of course won't work in this 
case. 
This number requires 33 bits to store.

I will look into ECMAscript support for long datatypes.  Can't believe I didn't 
catch
this myself.  My apologies, this should have been obvious long ago.  Nice find, 
and
thanks again for the data, without which this analysis would not have been so 
simple.

Original comment by andrew.h...@gmail.com on 9 Dec 2007 at 8:09

GoogleCodeExporter commented 9 years ago 
Upon closer inspection it seems that this is actually a Microsoft problem.  
Sigh. 
System.Shell.Item.Size is *supposed* to be a long, but is actually a signed 
32-bit
integer, meaning the gadget will incorrectly calculate the size as negative for 
any
file whose size is greater than 2GB and less than 4.  It then will oscillate 
between
positive and negative for ranges 6-8, 8-10, and so on, always in the range +/- 
2 GB.

I have discovered that by accessing this same property as "metadata" of the 
file it
may be possible to work around this.  For example if I make a file of size
2,908,422,144, then accessing the System.Shell.Item.metadata("Size") property 
gives
back the correct number whereas System.Shell.Item.size yields "-1386545152".

Unfortunately if I try to access the same property for a file of size 
5,816,844,288,
I get back undefined.

I'll continue to research this.  I should be able to deal with files up to 4GB 
using
the metadata workaround but there are certainly bigger files too... 
Unfortunately
this might not be an easy solution.

Original comment by andrew.h...@gmail.com on 9 Dec 2007 at 9:51

GoogleCodeExporter commented 9 years ago 
OK, a solution has been found but it's pretty ugly.  I will create an ActiveX
FileSystemObject control up-front and use that to get the size instead, as it 
can
reliably read sizes up to at least 5.6 GB.  I presume that since 5.6 GB is well 
on
the other side of 4.0 GB, it will read all valid file sizes up to 63 bits in 
length,
which is a good ways away from being a dangerous boundary at the present time.  
Who
knows, maybe it will even handle 64 bit...

If you're watching this issue, gregsieg, I'd like to ask you to re-test this 
case
with a special build.  I'm running Vista Ultimate but its 64-bit; I'd like to 
confirm
this workaround will function on a 32-bit system before releasing it.

Thanks again.

Original comment by andrew.h...@gmail.com on 9 Dec 2007 at 10:21

GoogleCodeExporter commented 9 years ago 
Hi,Would be happy to work with you to test your changes/fix.  Just let me know.

Regards,  Greg

Original comment by gregs...@gmail.com on 9 Dec 2007 at 1:18

GoogleCodeExporter commented 9 years ago 
Hi Greg,

Thanks for offering to help.  If you are still willing, please download this 
version
of the gadget (make sure to uninstall the old one first):

http://www.andrewlynchhayden.com/folderslice/folderslice-0.9.4.gadget

This version contains some other improvements, most notably it should be more
responsive.  Please let me know if it works for you, and whether your copy of 
Vista
is 32- or 64-bit.  You can e-mail me directly at andrew.hayden (at) gmail (dot) 
com.

Thanks!

Original comment by andrew.h...@gmail.com on 11 Dec 2007 at 8:10

GoogleCodeExporter commented 9 years ago 
Adding tags for issue filtering.

Original comment by andrew.h...@gmail.com on 11 Dec 2007 at 8:13

GoogleCodeExporter commented 9 years ago 
Thanks, Greg, for testing this out.  I've added a thanks in the release notes as
"Greg S".

Released into 0.9.4.

Original comment by andrew.h...@gmail.com on 12 Dec 2007 at 6:34