Страница 2 из 4

Добавлено: Ср мар 26, 2008 19:39
D1P
Я из дркб первое попавшееся вытянул.

Добавлено: Пн мар 31, 2008 18:17
Осипов Сергей
D1P писал(а):Когда руки дойдут.
Спасибо за плагин.
Поюзал немного, пока диск был битый.
Помогло.
Удачи!

Добавлено: Вт ноя 04, 2008 17:07
Plumber
Осипов Сергей писал(а):Поюзал немного, пока диск был битый.
Помогло.
А у меня и диски вроде бы не битые, а не помогает :? Плагин работает как-то кривенько (а может это у меня руки такие), после нажатия на кнопочку "ОК" - давай паковать, то бишь копировать, появляется градусник, но в нем ничего нет (так что о происходящем приходится только догадываться), а затем, чаще всего вываливается окно с сообщением "External exeption EEDFADE please report this error to the Author with a description ....", или Командир зависает так, что приходится рубить через диспетчер задач.
Автор забросил свое творение - это и понятно, тема видимо не слишком актуальна, а я к сожалению в програмировании, как свинья в апельсинах :cry: .

Раньше как-то не сильно обращал внимание на подобные коллизии, копируешь, процесс идет нормально, запускаешь проверку - тоже вроде бы без каких-либо заморочек, шустренько так. Только по прошествии некоторого времени запускаю повторную проверку CRC и оказывается, что из четырех файлов(~500Mb каждый) два нормальные, а два - CRC Error. В поцессе игрищ заметил, что последние скопированные файлы проверяются без обращения к устройству :?: . Начал играться с настройками TC в разделе "Операции с файлами" - результат нулевой, пробовал через консоль с верификацией - те ж грабли (сообщение об удачном завершении опрации, а после перезагрузки машины - CRC Error).
Все выше описанное чаще всего происходит при копировании HDD->USB и USB->USB, в обратную сторону (USB->HDD), такие артефакты наблюдаются гораздо реже.
Перерыл половину интернета в поисках софта, способного решать подобные задачи, но увы. Да, есть программы для копирования информации с битых носителей, многие из них нечитаемые области заполняют чем попало, но это может быть хорошо для видео-аудио (часть потерял, но основное сохранил), а как быть с бинарниками? Там нолики вместо полезной информации не очень-то катят.
Уважаемые форумчане! Обращаюсь к вам за помощью, может кто, владеющий программированием, возьмется доработать плагин уважаемого D1P, благо исходники есть, а так же он сам подсказал интересную (на мой взгляд) идею:
грузить по частям или в потоке. Или вообще не использовать память.
Это конечно медленнее, но для таких случаев как у меня, можно пожертвовать скоростью ради качества.
В идеале (но это уже к Гислеру) хотелось бы поиметь настройки режима прямо в окне копирования.

Добавлено: Пт ноя 07, 2008 10:09
Моторокер
Plumber писал(а):В идеале (но это уже к Гислеру) хотелось бы поиметь настройки режима прямо в окне копирования.
Очень сомневаюсь, что большинству пользователей понадобится эта функция.
Если есть проблемный usb, его проще выкинуть и купить новый, благо, стоят копейки.
Plumber писал(а):программы для копирования информации с битых носителей, многие из них нечитаемые области заполняют чем попало
А что, пардон, писать на место байт, содержимое которых неизвестно? Заполнять случайными символами, авось, может и подойдёт? Или перебором заполнять, может exe запустится?

Может, всё же с железом пробемы? Негоже их решать софтовыми способами.

Добавлено: Пт ноя 07, 2008 17:20
Tol!k
Plumber писал(а):В поцессе игрищ заметил, что последние скопированные файлы проверяются без обращения к устройству ... пробовал через консоль с верификацией - те ж грабли (сообщение об удачном завершении опрации, а после перезагрузки машины - CRC Error).
А что если отключить кэширование записи для проблемного диска?

Добавлено: Сб ноя 08, 2008 03:26
Plumber
Если есть проблемный usb, его проще выкинуть и купить новый, благо, стоят копейки.
То что стоят копейки, не совсем согласен, смотря какой, тем более, что по USB можно подключать и внешние HDD, которые стоят совсем не копейки. А если USB исправный и проблема совсем не в нем?
А что, пардон, писать на место байт, содержимое которых неизвестно? Заполнять случайными символами, авось, может и подойдёт?
Ну да, попробовать подобрать пару десятков(сотен) байт в EXEшнике :wink: Для видео и музыкальных файлов, это не столь проблематично - потеряете оди-два кадра, можно и не заметиь, в архиве, если в нем содержится информация для восстановления, еще можно попытаться востановить, а вот с исполняемыми файлами такие фокусы, увы не проходят.
Может, всё же с железом пробемы? Негоже их решать софтовыми способами.
IMHO, как раз для таких случаев и нужен софт, далеко не всегда можно оперативно определить, что проблема именно в железе, а тем более эту проблему исправить, а информацию в полном объеме нужно снять.
А что если отключить кэширование записи для проблемного диска?
Вообще-то кеширование для съемных носителей отключено по умолчанию, а как быть с кешем самого винчестера :?: каким образом отключить его :?:
Это все лирика, на сегодня, пока нашел только одно удобоваримое решение - программа KillCopy (не сочтите за рекламу, хотя продукт этого достоин). Очень хотелось бы поиметь подобную функцию встроенную непосредственно в Коммандер. Попытаюсь более подробно описать ситуацию:
Есть несколько заведомо исправных носителей, подключаемых по USB интерфейсу, при копировании с USB на HDD обычно все поисходит нормально, без каких-либо потерь, а вот в обратную сторону или USB->USB, получается полная лажа, что самое неприятное, проверка CRC сразу после копирования проходит очень быстро(судя по сотоянию индикатора, без считывания информации непосредственно с носителя-приемника) и показывает полное соответствие оригиналу. После перезагрузки компа (софта очищающего память под руками нет) и повторной проверке CRC (в этом случае проверка проходит намного медленнее и непосредственно считыванием проверяемого файла) обнаруживается несоответствие контрольной суммы, равно как и при сравнении файлов по содержимому.
В поцессе экспериментов удалось частично локализовать проблему, заключавшуюся в ручной настройке таймингов памяти на уровне BIOSa, при чем речь не идет о разгоне, а об оптимальных установках для этого типа памяти (Samsung DDRII), при установке в AUTO и использовании KillCopy, файл копируется правильно с первой попытки и проверка выпоняется нормально, т.е. непосредственно считывая проверяемый файл. Видимо Гислеру не мешало бы изменить хотя бы алгоритм проверки CRC, что бы этот процесс был более достоверным, пусть даже в ущерб скорости. Здесь сама по себе напрашивается поговорка о ловле блох :lol:

Добавлено: Сб ноя 08, 2008 09:30
Tol!k
Вообще-то кеширование для съемных носителей отключено по умолчанию
По умолчанию файлы не портятся

Как отключить кэширование флэшки/USB-flash?
Оптимизировать для быстрого удаления

Добавлено: Сб ноя 08, 2008 15:20
Plumber
Tol!k писал(а): Как отключить кэширование флэшки/USB-flash?
Оптимизировать для быстрого удаления
Как это сделать я знаю, тем более, что речь не идет о быстром извлечении, и то что файлы не портятся по-умолчанию до недавнего времени был уверен на все 100%, но как оказалось на самом деле доверяй но ... И в этом случае хочется что бы проверка была настоящей проверкой, а не фиктивной.

Добавлено: Сб ноя 08, 2008 18:55
Вахмурка
Если необходимо совместить копирование с проверкой правильности оного, то рекомендуется использовать xxcopy. На страничке удобно сделать контекстный поиск строки /CDM - там все сказано.

Добавлено: Сб ноя 08, 2008 19:21
Plumber
Вахмурка писал(а):совместить копирование с проверкой правильности оного то рекомендуется использовать xxcopy
Спасибо за наводку, надо будет пощупать зверя за вымя :lol: может он чего и умеет.

Добавлено: Сб ноя 08, 2008 20:43
Вахмурка
Завидую тебе. У тебя впереди чарующее ощущение знакомства со "зверем"... Если заинтересовался, то почитай...

Добавлено: Вс июл 19, 2009 16:07
paradoxic
Ребята, есть какие-то изменения?
я тоже испытываю нужду в таком плагине.
У меня копирование на флешку идет с ошибкой, хотя на другом компе все нормально с ней. Приходится вручную создавать MD5 файл и проверять после копирования

Добавлено: Вт июл 21, 2009 00:21
Koljasik
попробуй использовать KillCopy

Добавлено: Вт июл 21, 2009 12:08
paradoxic
Я нашел причину:
если копировать на флешку средствами windows, то ошибок нет, а вот коммандер копировал с ошибками. так вот, в коммандере в "конфигурация->операция с файлами" нужно убрать галочку USB флеш-диски и будет вам счастье)))
но остается другая проблема: при копировании через коммандер с одного компьютера на другой по сети, возникает та же ошибка crc после проверки. и аналогично средствами windows ошибок нет.

Добавлено: Пн ноя 30, 2009 05:42
Silent Rain
Ситуация такая. Есть внешний винчестер с USB 2.0 - SAMSUNG MP0402H (он же Canyon Hard Disk Drive Portable) (40 GB | файловая система NTFS). Я на него копирую всякие резервные файлы посредством Total Commander 7.50a. Решил после записи на него резервных копий проверить их Hash сумму. Программу использовал и MD5summer 1.2.0.11 Beta, и делал CRC посредством самого TC. Большинство файлов на диске успешно прошли проверку на CRC, а это 99% файлов, но все же 1-2 файла провалили эту самую проверку (этот самый 1%). В чем дело? Почему так происходит? В чем может быть проблема? Проверял этот внешний винт на присутствие битых кластеров с помощью HD Tune, но он ничего не нашел, показав, что все в норме. Также проверял диск встроенными средствами проверки самой ОС (скриншот) и опять все нормально!

Моя конфигурация:
ОС: Windows 7 Ultimate x32
Материнка: ASUS P5K
Память: 2 GB
Процессор: Intel Core 2 Quad CPU Q6600 @ 2.40 GHz
Видеокарта: NVIDIA GeForce 8600 GT

Изображение
Изображение

P.S. Чтобы в дальнейшем быть уверенным в точности сделанных резервов, как можно автоматом сделать так, чтобы при копировании эти CRC сами проверялись? То есть, я копирую файлы на внешний USB HDD и если есть ошибка в CRC мне Total Commander об этом сразу заявляет.
P.S.S. И вообще, какие нужно в TC ставить опции, чтобы копирование было МАКСИМАЛЬНО точным и без ошибок??? Скорость не важна, важна ТОЧНОСТЬ, чтобы впредь не было таких ляпов и ошибок при копировании !!!!! Может есть какие-то общие советы ? :roll: