Plumber
|
 Posted: Sat Nov 08, 2008 04:26 Post subject: |
 |
|
| Quote: | | Если есть проблемный usb, его проще выкинуть и купить новый, благо, стоят копейки. |
То что стоят копейки, не совсем согласен, смотря какой, тем более, что по USB можно подключать и внешние HDD, которые стоят совсем не копейки. А если USB исправный и проблема совсем не в нем?
| Quote: | А что, пардон, писать на место байт, содержимое которых неизвестно? Заполнять случайными символами, авось, может и подойдёт?
|
Ну да, попробовать подобрать пару десятков(сотен) байт в EXEшнике  Для видео и музыкальных файлов, это не столь проблематично - потеряете оди-два кадра, можно и не заметиь, в архиве, если в нем содержится информация для восстановления, еще можно попытаться востановить, а вот с исполняемыми файлами такие фокусы, увы не проходят.
| Quote: | | Может, всё же с железом пробемы? Негоже их решать софтовыми способами. |
IMHO, как раз для таких случаев и нужен софт, далеко не всегда можно оперативно определить, что проблема именно в железе, а тем более эту проблему исправить, а информацию в полном объеме нужно снять.
| Quote: | | А что если отключить кэширование записи для проблемного диска? |
Вообще-то кеширование для съемных носителей отключено по умолчанию, а как быть с кешем самого винчестера  каким образом отключить его
Это все лирика, на сегодня, пока нашел только одно удобоваримое решение - программа KillCopy (не сочтите за рекламу, хотя продукт этого достоин). Очень хотелось бы поиметь подобную функцию встроенную непосредственно в Коммандер. Попытаюсь более подробно описать ситуацию:
Есть несколько заведомо исправных носителей, подключаемых по USB интерфейсу, при копировании с USB на HDD обычно все поисходит нормально, без каких-либо потерь, а вот в обратную сторону или USB->USB, получается полная лажа, что самое неприятное, проверка CRC сразу после копирования проходит очень быстро(судя по сотоянию индикатора, без считывания информации непосредственно с носителя-приемника) и показывает полное соответствие оригиналу. После перезагрузки компа (софта очищающего память под руками нет) и повторной проверке CRC (в этом случае проверка проходит намного медленнее и непосредственно считыванием проверяемого файла) обнаруживается несоответствие контрольной суммы, равно как и при сравнении файлов по содержимому.
В поцессе экспериментов удалось частично локализовать проблему, заключавшуюся в ручной настройке таймингов памяти на уровне BIOSa, при чем речь не идет о разгоне, а об оптимальных установках для этого типа памяти (Samsung DDRII), при установке в AUTO и использовании KillCopy, файл копируется правильно с первой попытки и проверка выпоняется нормально, т.е. непосредственно считывая проверяемый файл. Видимо Гислеру не мешало бы изменить хотя бы алгоритм проверки CRC, что бы этот процесс был более достоверным, пусть даже в ущерб скорости. Здесь сама по себе напрашивается поговорка о ловле блох  |
|
Rules
Search
FAQ
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
