#44 Large files apear to have corrupt sizes in browse window

[Anonymous]

While browsing today on the waste mesh I have setup
with some friends. I noticed that in the browse window
it showed some rather odd folder sizes. example:

Item Size
svcd 8 GB in 23 items
X.dvd-ds 4194303 GB in 1 items
spongbob 4 GB in 10 items

Once you browse into the X.dvd-ds folder then it shows
the following:

Item size
x.dvd-ds.iso 3.7GB

So in the folder it looks fine but when browsing the
folders it looks really strange. I have seen this on a few
directories with rather large single files. Hoping this info
will help you guys squash anothe bug. Me and my
friends have all be enjoying the Application. Keep up the
good work.

-Loafy

[Eric]

Logged In: YES
user_id=945916

Sounds like it might be a problem with the value overflowing
out of an int. I will look into it.

[Chris]

Logged In: YES
user_id=573676

I was unable to reproduce this. What platforms are the
sharing and browsing machines?

[Aaron]

Logged In: YES
user_id=1207360

In my case, the client is the server, running Windows XP
SP2. I just upgraded to 1-22-05 build of Waste. This did
not resolve the issue.

Great system guys!

[Aaron]

Logged In: YES
user_id=1207360

More info: I put a single file into a folder.

Windows reports the file size as: 3,047,916 KB.
Waste reports the file size as: 2.9 GB.
Waste reports the containing folder size as: 4194302 GB in 1
items.
This also corrupts the folder sizes further up the tree.

I hope this information helps.

[Tom]

Logged In: YES
user_id=1045619

Thanks fatespeaks for the filesize that corrupts it. While
I'm not a good coder and can't exactly say why the problem
occurs, the problem is that in & around 992 and 1011 of
srchwnd.cpp, the high length variable somehow gets set to a
ridiculously large value, causing waste to "whig out" (yes,
that's the technical term). Anywho, this only seems to
happen for a certain range of file sizes, and a quick fix
can be made by adding the following code segment at line
1347 (immediately at the beginning of the FormatSizeStr64
method)

if (high >= 1024*1024-1)
high = 0;

a side-effect of this is that if on waste there is more than
a few petabytes of information, the size will be displayed
incorrectly, though it's possible that that might happen
anyways. On waste, petabytes worth of information is
unrealistic, so this fix should work just fine for you :)

--theanomaly

[Tom]

Logged In: YES
user_id=1045619

Oops, I was wrong (kind of), I hadn't followed the error
back far enough. While the previous does fix the problem
(though it's a quick fix and only for viewing, the actual
size variable remains messed up), I've found the actual
problem. The problem occurs in filedb.cpp where the
poosize/length_high variables are set to length_high*4096 +
length_low>>20. The problem with these lines of code are
that if the most significant bit of length_low is set to 1,
the bitshifts will fill in the leftmost bits with 1's
instead of zeros. Therefore, change these existing lines of
code in filedb.cpp to the following:

Line 431:

poosize=(m_database[x].length_high * 4096)+(((unsigned
int)m_database[x].length_low)>>20) + (dbsize_errcnt < o);

Line 443:

repl->addlastsize(1,(m_database[x].length_high *
4096)+(((unsigned int)m_database[x].length_low)>>20) +
(dbsize_errcnt < o),m_database[x].file_time); //if
dbsize_errcnt wraps, then we should tack another mb on there

Line 868:

m_database_mb+=(m_database[m_database_used].length_high*4096)
+ (((unsigned int)m_database[m_database_used].length_low)>>20);

By casting the ints to unsigned ints, the bitshifts will be
ensured to 0-fill instead of 1-fill if the most significant
bit is set.
Cheers

[ligoten]

Logged In: YES
user_id=1428972

I attempted this fix recently, and I noticed that while
the individual file sizes appeared to display correctly,
the total share size had a considerable offset in it
between the user list and the root directory of my share.
Is this another representation of the same bug, or another
one entirely (the total share size is over 700GB)?