Freeze while copying or moving large amounts of data > 250mb from SMB > SD or SD > USB or SD > SMB or SMB > USB or USB > SMB

[GoogleCodeExporter]

What steps will reproduce the problem?

1. press (+) on a folder containing a FS dump with 328mb+ of data in many 
thousands of small files
2. choose copy or cut from the context menu that appears
3. select OK in pop up menu that appears
4. move to a different location preferably on another device
5. press (+) anywhere
6. choose paste from the context menu that appears
7. press the yes to all button if a pop up appears for overwriting one of your 
previous failed copy or moves

What is the expected output?

files copy correctly
or
files move correctly

What do you see instead?

1) time remaining is a random number between INT_MIN and INT_MAX
2) copied size is an amount greater than 4mb but out of just 3mb for example 
(32.4mb / 3.6mb)
3) minimizing seems to help sometimes rarely maybe because it is a different 
thread priority and not slamming the cpu with figuring out the invalid time 
remaining and doing bad math
4) between 33% + 66% the copy or move ill stop you can click minimize or cancel 
but once you click either you cannot click that button again and it changes 
nothing
5) could this be long timed copies that have higher priority than the rendering 
thread and the main thread kill those threads because they dont get a time 
slice for too long?

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

r212
r213
r214

Please provide any additional information below.

doesn't seem to matter what the source and destination devices are i have tried 
2 different sd cards 3 pcs with smbs and 3 usb drives

Original issue reported on code.google.com by andi.ire...@gmail.com on 25 Jul 2011 at 3:28

[GoogleCodeExporter]

I just copied a 512 MB file from SD to SMB without any problem or wrong 
calculations on r212.

A known issue is a freeze when writing to USB with IOS58. I usually use IOS202, 
are you on IOS58? If so, is it possible for you to try IOS202? 

Original comment by dimok...@hotmail.de on 25 Jul 2011 at 2:51

[GoogleCodeExporter]

Hi Dimok,

I actually noticed this same problem when transferring a large amount of 
console ROMs from SD to USB (~100MB).  It looks like one or more of the 
variables is overflowing.  I will try to track it down in the code when I get 
home from work.

Perhaps on a related note, I also received a code dump while doing this same 
transfer.  I tracked it down to the fact that when properly renamed with 
Cowering's GoodTools, some of the ROMs contain an extra "." (period character) 
within the name ( e.g. "Dr. Mario (JU) (PRG1) [!].zip").

Once I removed the offending ROMs the copy went through without a hitch (albeit 
with the aforementioned percentage/time remaining glitches).  Glad to see 
WiiXplorer and USB-Loader still going strong given that most people think the 
Wii Scene is dead!

-Claw

Original comment by clawiifi...@gmail.com on 26 Jul 2011 at 11:33

[GoogleCodeExporter]

Actually the filename does not matter. For WiiXplorer it is just a string it 
gives over to the filesystem libraries. There is a lot that goes wrong in the 
filesystems it seems, especially in libfat. I am thinking of disabling the 
"background copy" feature which causes a lot of problems because of instability 
of the threads.

About the overflows, this could be in the progress thread and is an easy fix to 
limit though. This will not help with the crashs though.

Original comment by dimok...@hotmail.de on 27 Jul 2011 at 7:35

[GoogleCodeExporter]

its not just background copies that fail its any copy at all

Original comment by andi.ire...@gmail.com on 27 Jul 2011 at 1:07

[GoogleCodeExporter]

That's because all copies run over that "background thread".

Original comment by dimok...@hotmail.de on 27 Jul 2011 at 2:29

[GoogleCodeExporter]

you could just make sure you yield a certain amount of time for the main thread 
and network thread whichever thread is exploding because its being blocked out 
by the copy thread

Original comment by andi.ire...@gmail.com on 27 Jul 2011 at 5:27

[GoogleCodeExporter]

Not sure how the threading works or why this freezes but it seems that the copy 
thread just does not let up enough for the main thread which hangs causing 
everything to choke

Original comment by andi.ire...@gmail.com on 28 Jul 2011 at 5:32

[GoogleCodeExporter]

Well as I said before this issue is only present when copying data from or to 
USB with IOS58. The code isnt stable enough. Use a d2x IOS or Hermes IOS 
instead.

Original comment by dimok...@googlemail.com on 10 Jun 2012 at 12:49

• Changed state: Invalid

[GoogleCodeExporter]

Btw this is an issue in libogc as the handle for USB with IOS58 is in there.

Original comment by dimok...@googlemail.com on 10 Jun 2012 at 12:49

[GoogleCodeExporter]

actually i always use d2x IOS

Original comment by andi.ire...@gmail.com on 15 Jun 2012 at 1:02

[GoogleCodeExporter]

There was no way you could have used a d2x IOS before revision 227. Only Hermes 
202/222/223 was available until that and IOS 60 and below.

By using another IOS i mean really go into settings and set up that IOS as 
"Boot IOS". From revision 227 and above it is possible to use any IOS the user 
wants.

Original comment by dimok...@googlemail.com on 25 Jun 2012 at 5:20

[GoogleCodeExporter]

I had the same issue where transferring a large file would always eventually 
hang, both when using WiiXplorer as an FTP server and copying and pasting the 
file from a SMB share.  Manually updating the IOS setting from 58 to 202 in the 
WiiXplorer config file fixed this for me.

Original comment by Aoibhean...@gmail.com on 6 Apr 2013 at 6:59