Yeah, that would make sense. One of the things we can prove have caused this is the opening and closing of the xD card bay while a dictation file is currently being written. We've watched some docs rapid fire flip it open and closed, which doesn't cleanly eject the disk.
<br><br><p><DEFANGED_div class="gmail_quote">On Nov 29, 2007 12:24 PM, Collin Kidder <<a href="mailto:adderd@kkmfg.com">adderd@kkmfg.com</a>> wrote:<br><blockquote class="gmail_quote" DEFANGED_style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Something Casey said made me think of another potential suggestion:<br><br>Some versions of windows default to write caching even flash drives. If<br>windows does that and somebody yanks the drive without properly stopping
<br>the device first then they run the risk of blowing the fat table. This<br>could be prevented by forcing windows to not write cache the drive.<br><p><DEFANGED_div><p><DEFANGED_div></p><DEFANGED_div><p><DEFANGED_div class="Wj3C7c"><br>Justin Popa wrote:<br>> All great suggestions, but they are doctors, so they get their way.
<br>> Infrequent downloading because they're too busy most of the time. We also<br>> had originally set up a 'never to leave the office with this device' policy,<br>> but now we're replacing about 1 a month due to lost items(lost at home, in
<br>> another state, on a plane, in the lake). That's why I'm more in the mood of<br>> finding some decent recovery software than changing how they handle them.<br>> It's just impossible. Anyway, I found Runtime Software's "GetDataBack for
<br>> FAT" that runs on Windows. It's recovered them and seems to be working fine.<br>><br>> On Nov 29, 2007 11:52 AM, Ben Rousch <<a href="mailto:brousch@gmail.com">brousch@gmail.com</a>> wrote:<br>
><br>><br>>> I'd suggest increasing the frequency of cradle visits. When the<br>>><br>>>> machines corrupt the drives, is the most-recently-recorded data also<br>>>> corrupt, or just the other data that hasn't seen a cradle yet?
<br>>>><br>>>> I seem to recall that the FAT filesystems have a backup table, too.<br>>>> But it's been ages since I fiddled with fsck.vfat<br>>>><br>>><br>>> I would suggest reformatting the cards more frequently. I have had similar
<br>>> problems with card corruption in a digital camera and frequent reformatting<br>>> seems to have fixed that problem. Considering the medical nature of the data<br>>> being stored, pull each card aside once a week and format it to be safe. You
<br>>> might also consider tracking corruption for each card so you can tell if<br>>> it's one or two cards that are the problem, or the whole batch.<br>>><br>>><br>>> _______________________________________________
<br>>> grlug mailing list<br>>> <a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>>> <a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
</a><br>>><br>>><br>><br>><br></p><DEFANGED_div></p><DEFANGED_div>> ------------------------------------------------------------------------<br><p><DEFANGED_div><p><DEFANGED_div></p><DEFANGED_div><p><DEFANGED_div class="Wj3C7c">><br>> _______________________________________________
<br>> grlug mailing list<br>> <a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>> <a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
</a><br><br>_______________________________________________<br>grlug mailing list<br><a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br><a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">
http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br></p><DEFANGED_div></p><DEFANGED_div></blockquote></p><DEFANGED_div><br>