Max Diesel писал(а): ↑Чт фев 02, 2017 4:03 am
i3v писал(а): ↑Вт янв 31, 2017 8:36 pm
И ещё я опять на днях наткнулся на следующую штуку (кажется, я ещё её не описывал):
- UC beta8.
- Запускаем поиск чего-нибудь. Находим несколько папок.
- Скармливаем их в панель
- Делаем "Commands->Calculate size of subdirs" - UC для всех папок показывает нулевой размер (хотя если в папку зайти - внутри всё видно нормально, и размер не 0).
Да, действительно баг. Благодарю за содействие, со следующего билда будет корректно. Этому багу буквально два дня до пенсии оставалось.
В beta9 вылечилось, спасибо!
Max Diesel писал(а): ↑Пт фев 10, 2017 5:59 am
i3v писал(а): ↑Ср фев 08, 2017 2:44 pm
И ещё один баг:
UC странно себя ведёт при попытке создать ярлык на Win7 (длинный правый клик в панели -> контекстное меню -> new -> shortcut). В панели сразу отображается "New shortcut.lnk", в режиме переименования. При этом окрывается стандартный мастер создания ярлыка windows, на втором шаге предлагающий задать имя ярлыку. Если я в "мастере" задаю имя "aaa" и выхожу из него - UC не только не отображает мне вновь созданный ярлык, но и по-прежнему предлагает переименовать тот файл (которого уже нет).
Хм... я действительно не предполагал вариант с системным созданием ярлыка. К следующему билду добавлю пару подпорок, в связи с чем в этом плане станет корректнее. Благодарю за эту полезную информацию.
Теперь, в beta9, конечно, тоже не идеально (хотя и обновляет сразу после завершения "мастера создания ярлыка" - всё равно изначально отображает ярлык в режиме переименования, что несколько запутывает). Ну да ладно, всяко так уже заметно приятнее
. Если я правильно понимаю, тут проблема в том, что не так-то просто отследить, что именно было нажато в контекстном меню и собирается ли оно само переименовывать файл...
Max Diesel писал(а): ↑Пт фев 10, 2017 5:59 am
i3v писал(а): ↑Ср фев 08, 2017 2:55 pm
И ещё одна мелочь:
При переименовании диска (флешка обозначенная как "E" на скриншотах) из "VERBATIM" в "U3CTR_KEY" (стандартным образом, через "правый клик по иконке диска -> properties") не обновляется имя диска в "заголовке панели", хотя в двух других местах (всплывающая подсказка и строка над вкладками) всё обновляется сразу.
Спасибо, со следующего билда предположительно будет корректно.
Починилось, спасибо!
Max Diesel писал(а): ↑Пт фев 10, 2017 5:59 am
i3v писал(а): ↑Ср фев 08, 2017 4:05 pm
я выделяю "a*.txt" и ставлю считаться хеши (файлом по умолчанию будет "C:\temp\temp.md5", и я его не меняю). Допустим, файлы достаточно большие и хеширование займёт хотя бы секунд 20. Пока оно хешируется, выделяем "b*.txt" и ставим считаться хеши точно так же (файлом по умолчанию будет тот же файл... что я изначально не заметил), параллельно.
Потом с удивлением наблюдаем, что в конечном файле записи с "a*.txt" чередуются с записями "b*.txt". Что немного странно. Результат интересный и хороший, но возникает подозрение - оно правда специально предполагалось для такой работы? thread-safe ли оно? Или оно, при определённом уровне удачи, таки попытается записать две "записи" одновременно и что-то сломает? (Я, правда, такого момента не поймал, но и не пытался).
В случае если два потока попытаются сохранить хэш одновременно, теоретически должно отобразиться окно о невозможности доступа к файлу. Как бы то ни было, со следующего билда добавлю еще дополнительно и защиту для такой ситуации.
Если на глаз - вроде бы поведение не изменилось. Просто оно теперь так или иначе корректно учитывает то, что писать могут несколько потоков, и можно пользоваться безбоязненно, я правильно понимаю?
И ещё одна штука произошла на beta8 - ставил на ночь длительное копирование-через-синхронизацию и ещё одно менее длительное перемещение. Всё в одном UC. Но ни то ни другое не завершилось ("синхронизация" повисла ещё на копировании), а окна этого UC повисли. В fl_error.txt следующее:
Код: Выделить всё
Invalid pointer operation|00830162 3 2016-08-01 22:27:50 1160 9fca05c5
x64 Invalid pointer operation|00832742 1 2016-08-19 15:45:37 1162 563a3e0c
x64 Access violation at address 000000000060C9F9 in module 'UnrealCommander64.exe'. Read of address 0000000000000030|00000000 1 2016-08-21 17:43:59 1163 530022ce
x64 Access violation at address 0000000000543D52 in module 'UnrealCommander64.exe'. Read of address FFFFFFFFFFFFFFFF|00543D52 1 2016-10-06 16:34:31 1163 80382adb
x64 Invalid pointer operation|00833212 12 2016-10-06 16:34:31 1163 11282a31
x64 Invalid pointer operation|0083C9D2 12 2016-11-15 03:38:04 1164 01197c67
x64 Invalid pointer operation|00841292 63 2016-12-13 14:48:38 1166 29b57961
x64 Invalid floating point operation|00000000 14 2016-12-18 18:26:45 1184 c75ec877
x64 Access violation at address 0000000000614839 in module 'UnrealCommander64.exe'. Read of address 0000000000000030|00000000 1 2016-12-26 13:31:52 1184 df89b4a4
x64 Invalid pointer operation|00843452 20 2017-02-05 03:06:34 1184 77d92ced
x64 1 308 2017-02-10 19:29:13 1193 8a47c823
x64 Invalid pointer operation|000000000085D7F2 50 2017-02-12 12:31:13 1193 27f1bad9
Относиться к делу, тут, наверное, может только последняя строчка. Да и то я не уверен - судя по тому, как мало оно сделало - оно повисло гораздо раньше, чем 12:31. Хотя если это дата
последней ошибки из 50 - может быть это как раз оно. Файлов было ~250 тыщ, ~3 ТБ. Потребление памяти UC пиковое ~360 МБ.
Чтобы хоть как-то помочь локализовать проблему, привожу скриншоты Process Explorer'а, в котором я попытался посмотреть на то, как меняется стек самого активного потока висящего UC (см. вложенный архив).
Сравнил "источники" и "получатели" - нашёл файл на котором всё оборвалось. Из ~30МБ записана примерно четверть, а остальное - нули. Это один из файлов, который "перемещался" с локального HDD в сетевую шару.
Синхронизация была с внешнего USB в ту же сетевую шару (но точно в другую папку, не пересекающуюся с той, в которую "перемещалось").