Mathis

Hey, I got one small bug/problem and maybe a cool feature idea. The problem: I removed a harddisk (button "Remove...") and placed a new drive. The new drive is still being recognized as the old vendors model. How can you reset this information? The idea: While safely removing the drive, all resources being available should be used to copy the data over to the new drive, to maximize the data throughput. Mostly the new drives are simply faster than the old drive, so when striped reading out the other disks, the new drive may be capable of writing in the same speed. Currently only one drive is being used for copying, so the throughput is limited by maybe an older and slower drive model. It should be optional, so the user can choose whether to use striped reading for duplication to the new drive or not.

Sadly the disk said byebye forever, so I give up. Most files are being recovered before trying this anyway...

I checked the log files, they are being modified from half a day before scanning the disk, so I doubt you could find anything useful inside. The memory dump of the service is (uncompressed) 1GB and compressed (7z) about 180MB in size, you really want it? My upload speed isn't really fast at all...

Hello again, I tried the new BETA 2.5.2.3069, the original bug seems to be fixed - thanks for quickly fixing it. Another bug raised: when starting the File Scan, several damaged files are being shown and after a while I get something like <see screenshot>. The window cannot be moved or anything, clicking inside doesn't bring up any reaction, the CPU and harddisk is being used heavily. Maybe you can give me a hint, how to diagnose it or send you a bug report (it doesnt produce any visible error message). Conservation of bugs law: a bug can never be removed or created new, it can only be transformed into another bug, the amount of bugs in a system is constant.

The inquiry is being sent.

Hello, the scanner found 7105 unreadable sectors (after scanning 4 days). Now I wanted to let the "File scan" feature identify which files are being affected for trying to recover them. Sadly it doesn't do anything except reporting "The index was out of range." I suppose this is a bug. Maybe you can suggest me a workaround?