Jump to content

LudoA

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by LudoA

  1. I was wondering what kind of random read speed others are seeing when executing 'Benchmark Drive'? For me, the result is 1.30MB/s (with 19% fragmentation). This is awful of course, but I have no idea how Defraggler does the random read speed test, so maybe results are low for a lot of people. Anyway, as such a number on itself doesn't say a lot without numbers to compare it to, I thought it'd be interesting if others posted their read speed as well, and the disk they're getting the results on. This is on a Seagate ST9320423AS (a Momentus 7200.4 SATA 3Gb/s 320-GB disk), Windows 7 and version 2.08.373 of Defraggler.
  2. Version 1.09.132 seems to have resolved the problem I reported here. However, doing a "defrag freespace" after a normal defrag often seems to trigger a crash. Don't have more specifics now, have no time for it, but will try to generate a debug log again. I don't remember having many (any?) crashes before 1.08.132, though, should this help in finding the bug.
  3. Hi, It crashed when I was using it with the /debug param. I think the steps I did were an analyze, then I selected all files +/- below 60 MB and defragmented those. This worked. Then I did an analyze again I think and it crashed. Not 100% sure of the steps I executed, however. Attached is the end of my debug file, let me know if you need more. Also, if there are debug symbols you want me to download somewhere, or if you want me to run windbg on it, let me know. defraggler_crash.txt defraggler_crash.txt
  4. I'm having the same problem with version 1.08.132. I haven't had this (a lot) before, but now I'm having it once about every 2 or 3 times as well. It doesn't completely freeze up or hang for me, though. It hangs for like 5 or maybe 10 seconds, but then it crashes and I get the Microsoft "report error" dialog. I'm running it now with the "/debug" param, in the hopes of catching it this way. Out of principle, it does disturb me that the file which debug-mode generates contains names of files on my disk, but maybe I'll just have to remove those and then submit the debug log (supposing the bug still appears in debug mode). Kyle, maybe you could also try with the /debug param (e.g. typing "c:\program files\defraggler\defraggler.exe /debug" in a cmd.exe window) and see if you can get a debug log of the crash happening?
  5. Hi, There are basically three types of protocols for digital camera's, either it's USB mass storage (which is automatically supported by Recuva, since it's a drive like any other), there's proprietary protocols (which can't be supported easily and are becoming rare anyway), and there's PTP, which is open and widely used. It would be very, very cool if this was supported, since it would enable the recovery of pictures (and any other files, of course) on a wide range of digital cameras. Right now, to recover pictures, I need to use gphotofs to mount the camera under GNU/Linux and then use some other - probably inferior - recovery software... Though I could try to create an image from the mounted disk, get that on a Windows machine, mount it with something like daemontools and then use Recuva, it would much easier if Recuva supported this... Possibly support for the protocol wouldn't have to be completely written, but something like libptp or maybe code from gphoto could be reused. Any chance of Recuva supporting this in the future? (Though I personally think both GNU/Linux and Windows should simply present PTP-camera's like a USB mass storage device to the end user, i.e. by mapping a drive (D:\ or /dev/sdX0) to it, which would automatically enable Recuva (and many other apps) to work with them.) Either way, thanks for creating Recuva, it's an extremely useful and very userfriendly tool!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.