Баги в v3.57 (build 1182-1465)

[Max Diesel]

Имеется ввиду вынос Табов каталогов? Например справа, несколько табов катологов на сетевых дисках с настройкой "Лок-таб, выход с возвратом"? Таких у меня 7 штук.
И раньше, когда стояла Винда 7ка, таких проблем не было.

Нет, речь не про табы каталогов. Речь про ситуацию, когда на панель инструментов (она вверху) вынесен каталог из сети. Соответственно он отображается в виде кнопки. Вот так:

В этой ситуации программа полезет в сеть за значком каталога, впрочем тогда подвисание программы будет при запуске, а не при возвращении в окно. Я не могу с уверенностью сказать, что виноват Windows, однако есть подозрение что он каким-то образом причастен. Чаще бывает, что причастность Windows'а связана не с самой операционной системой, а с фактом установленности программ, которые как-либо создают трудности другим программам.

[NukliON]

Нет, речь не про табы каталогов. Речь про ситуацию, когда на панель инструментов (она вверху) вынесен каталог из сети. Соответственно он отображается в виде кнопки. В этой ситуации программа полезет в сеть за значком каталога, впрочем тогда подвисание программы будет при запуске, а не при возвращении в окно. Я не могу с уверенностью сказать, что виноват Windows, однако есть подозрение что он каким-то образом причастен. Чаще бывает, что причастность Windows'а связана не с самой операционной системой, а с фактом установленности программ, которые как-либо создают трудности другим программам.

На панели инструментов все стандартно.

[Paul_TC]

При попытке создать копию файла нажатием Shift+F5 ничего не происходит, если в текущем имени файла первый символ "!"
Например "!bla-bla.txt"

[Max Diesel]

При попытке создать копию файла нажатием Shift+F5 ничего не происходит, если в текущем имени файла первый символ "!"
Например "!bla-bla.txt"

Действительно так и есть. Интересный баг. Спасибо за эту информацию, со следующего билда предположительно будет корректно.

[Pinguin]

Добрый день.
В компьютере установлен внутренний кард-ридер, позволяющий читать USB флэшки, SD, CF, MS. Система каждому из типов подключений присвоила букву диска, это можно увидеть в "управлении дисками".

Screenshot_27.png (8.4 КБ) 1535 просмотров

Что интересно, в "Моем компьютере" эти буквы диска не отображаются. Но если вставить в карт-ридер карту памяти, то появится буква и, соответственно, содержимое карточки.
Так вот, в UC по какой-то причине отображаются все эти буквы дисков, даже если в кард-ридер ничего не вставлено.

Screenshot_28.png (4.93 КБ) 1535 просмотров

Как итог - если вставить карточку памяти, то в "Моем компьютере" появится лишь одна буква диска, все наглядно и понятно. Если же открыть UC - то имеем целый список дисков, и какой из них открывать - непонятно.
Не уверен, является ли это ошибкой программы, но может имеет смысл скрывать неиспользуемые буквы дисков (проводник ведь сумел их скрыть), либо выводить под кнопками дисков заголовки подключенных томов, либо еще каким-то более удачным способом. Спасибо.

[Max Diesel]

Добрый день.
В компьютере установлен внутренний кард-ридер, позволяющий читать USB флэшки, SD, CF, MS. Система каждому из типов подключений присвоила букву диска, это можно увидеть в "управлении дисками".
Screenshot_27.png
Что интересно, в "Моем компьютере" эти буквы диска не отображаются. Но если вставить в карт-ридер карту памяти, то появится буква и, соответственно, содержимое карточки.
Так вот, в UC по какой-то причине отображаются все эти буквы дисков, даже если в кард-ридер ничего не вставлено.
Screenshot_28.png
Как итог - если вставить карточку памяти, то в "Моем компьютере" появится лишь одна буква диска, все наглядно и понятно. Если же открыть UC - то имеем целый список дисков, и какой из них открывать - непонятно.
Не уверен, является ли это ошибкой программы, но может имеет смысл скрывать неиспользуемые буквы дисков (проводник ведь сумел их скрыть), либо выводить под кнопками дисков заголовки подключенных томов, либо еще каким-то более удачным способом. Спасибо.

Добрый день || ночь || утро || вечер.
Выполните в командной строке Unreal Commander'а следующую команду:

Код: Выделить всё

HideRemovableNoMedia=1

Вероятно это даст желаемый эффект.

[Pinguin]

Max Diesel , спасибо огромное, команда помогла.

[i3v]

1. Частенько зависает на подсчете размера файлов, приходится снимать окно или убивать весь процесс.
2. Копируем файл в фоне, затем разворачиваем копирование, сворачиваем и копируем другой файл. Вот тут пропадает первое окно на панели, где отображается фоновое копирование с прогрессом. Иногда даже без разворачивания первая очередь пропадает. При этом второе копирование нельзя добавить к первому в очередь - ее просто нет в списке. Что еще примечательно: если вторую очередь свернуть, то на панели появляется и первая. Но как только разворачиваем например вторую, то первая с панели пропадает, как будто ничего не копируется.

1. Я однажды видел зависание на подсчете размера задания (вероятно речь идет именно про этот подсчет), однако к сожалению пока не удалось выяснить его причину. Если вдруг обнаружите способ спровоцировать проявление этого бага, то напишите мне.
2. Возможная причина этой проблемы была устранена, если вдруг в следующем билде проблема будет повторяться, напишите мне.

Я сейчас таки наткнулся на хорошо воспроизводимый пример, когда UC виснет на этапе "Подсчет размера задания..." он же "Calculating task size...".
Достаточно запустить проверку нескольких md5 подряд. Баг проявляется не только с проверкой md5 (по-моему - с любыми "Calculating task size..."), но именно для md5 легко построить хорошо воспроизводимый пример.

1. скачать и распаковать приложенный архив
2. запустить проверку вложенного md5 файла, раз 10 подряд, с минимальным интервалом между запусками.

За счёт большого размера md5 файла (10000 строчек) UC думает над "Calculating task size..." достаточно долго, чтобы баг наверняка проявился. В моём случае (UC build 1437) 7 из 10 появившихся окошек так и повисли на этапе "Calculating task size...". При этом размер задания в них разный и уже минут 10 не меняется.
И "Cancel calculation" не работает.

[i3v]

И ещё один странный баг, связанный с хешированием файлов:

1. Возьмём папку с какими-нибудь файлами, md5 для которых будет считаться хотя бы секунд 30. Например - распакованный архив из предыдущего сообщения.
2. Запускаем "File -> Create file hash (CRC) ...", сохраняя результаты в "03.md5", например.
3. До того как хеширование закончилось, запускаем то же самое ещё раз, сохраняя результаты в "04.md5", например.
4. Во втором окне нажимаем паузу. И... видим что фактически встали обе задачи (хотя красный прогрессбар только у второй, а у первой даже ETA ещё меняется какое-то время). Повторяемость - около 50% - в половине случаев первая задача продолжает выполняться, а в половине - паузится.

[i3v]

И ещё один странный баг, связанный с хешированием файлов:

1. Возьмём папку с какими-нибудь файлами, md5 для которых будет считаться хотя бы секунд 30. Например - распакованный архив из предыдущего сообщения.
2. Запускаем "File -> Create file hash (CRC) ...", сохраняя результаты в "04.md5"
3. До того как хеширование закончилось, запускаем то же самое ещё раз, сохраняя результаты в "05.md5"
4. До того как хеширование закончилось, запускаем то же самое ещё раз, сохраняя результаты в "06.md5"
5. В главном окне пытаемся открыть "04.md5" штатным просмотщиком (по F3). С некоторой вероятность получаем ошибку, что файл открыть невозможно. С некоторой вероятностью - окно штатного просмотрщика открывается, но файл в нём не загружен. С некоторой вероятностью - окно просмотрщика таки открывается, и содержимое файла в нём таки отображается.
   1. Судя по всему, UC постоянно открывает/закрывает "04.md5" (его даже переименовать можно - UC создаст новый), что наверняка сказывается на производительности... Может и не баг, но как-то неоптимально.
   2. Просмотрщик тоже не очень хорошо реагирует на гонку (зарепортил отдельно, тут, но шансов что починят, похоже, крайне мало...). Он может показать:
      • диалоговое окно "Universal Viewer" с ошибкой «Cannot open file: "n:\temp\UC_test_v3\04.md5"»
      • сообщение "File not loaded (choose menu File > Open)" в открытом основном окне (что, наверное, тоже, с некоторой натяжкой, можно считать корректной обработкой ошибки). В том числе, оно такое иногда вылезает после нажатия "OK" в предыдущем диалоге.
      • текст "VRichEdit" вместо реального содержимого файла (файл на самом деле не открыт) - явный баг связанный с гонкой тоже...
      • корректно открытый файл
6. Если файл таки открылся (что происходит с вероятностью порядка 10% и эта вероятность, похоже, тем выше, чем больше хеширований запущено параллельно в одном UC), вылезет сообщение о том что писать в файл не получается:
   

   Код: Выделить всё

   Unable to create a file/directory. Access is forbidden. 
   Cancel operation? 
   
   \\?\N:\temp\UC_test_v3\04.md5\
   -----------------------------------
   [Current]  [All]  [Retry]  [Skip]  
   -----------------------------------
   

   • Кстати, а слеш после "04.md5" - это баг или фича?.
7. Закрываем просмотрщик. Нажимаем "Retry".
8. Дожидаемся окончания хеширования.
9. Сравниваем "04.md5" и "05.md5" и видим, что в "04.md5" отсутствует одна строчка. Таким образом, Retry работает как-то некорректно (и это основной баг о котором я хотел тут рассказать...).

[Max Diesel]

Я сейчас таки наткнулся на хорошо воспроизводимый пример, когда UC виснет на этапе "Подсчет размера задания..." он же "Calculating task size...".
Достаточно запустить проверку нескольких md5 подряд. Баг проявляется не только с проверкой md5 (по-моему - с любыми "Calculating task size..."), но именно для md5 легко построить хорошо воспроизводимый пример.

1. скачать и распаковать приложенный архив
2. запустить проверку вложенного md5 файла, раз 10 подряд, с минимальным интервалом между запусками.

За счёт большого размера md5 файла (10000 строчек) UC думает над "Calculating task size..." достаточно долго, чтобы баг наверняка проявился. В моём случае (UC build 1437) 7 из 10 появившихся окошек так и повисли на этапе "Calculating task size...". При этом размер задания в них разный и уже минут 10 не меняется.
И "Cancel calculation" не работает.

Действительно, так и есть - при проверке хэшей если подсчет размера задания идет одновременно больше чем по одному заданию, то "коса находит на камень". Предположительно со следующего билда будет корректно, благодарю за содействие в обнаружении этого бага.

[Max Diesel]

И ещё один странный баг, связанный с хешированием файлов:

1. Возьмём папку с какими-нибудь файлами, md5 для которых будет считаться хотя бы секунд 30. Например - распакованный архив из предыдущего сообщения.
2. Запускаем "File -> Create file hash (CRC) ...", сохраняя результаты в "03.md5", например.
3. До того как хеширование закончилось, запускаем то же самое ещё раз, сохраняя результаты в "04.md5", например.
4. Во втором окне нажимаем паузу. И... видим что фактически встали обе задачи (хотя красный прогрессбар только у второй, а у первой даже ETA ещё меняется какое-то время). Повторяемость - около 50% - в половине случаев первая задача продолжает выполняться, а в половине - паузится.

Спасибо, это полезная информация. Действительно странный баг. Изменения внесены - предположительно со следующего билда будет корректно.

[i3v]

Действительно, так и есть - при проверке хэшей если подсчет размера задания идет одновременно больше чем по одному заданию, то "коса находит на камень". Предположительно со следующего билда будет корректно, благодарю за содействие в обнаружении этого бага.

Спасибо!
А обнаруженная проблема таки локальная, только для хеширования файлов, или для любюх "Calculating task size..."?

[Max Diesel]

А обнаруженная проблема таки локальная, только для хеширования файлов, или для любюх "Calculating task size..."?

Актуальна только для проверки хэшей.

[i3v]

А обнаруженная проблема таки локальная, только для хеширования файлов, или для любюх "Calculating task size..."?

Актуальна только для проверки хэшей.

Жаль... Ну да ладно, может ещё поймается когда...
------------------------
И ещё одну ошибку заметил в b1437.
Поставил ПК перезагружаться, штатным образом, через "пуск", не закрывая предварительно UC.
Вылезло системное окошко об ошибке:

Код: Выделить всё

---------------------------
UnrealCommander64.exe - Application Error
---------------------------
The exception unknown software exception (0xc0020001) occurred in the application at location 0x00007FFBBF80A388.


Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK   Cancel   
---------------------------

Из "fl_error.txt" (с запасом, мало ли, вдруг что-то полезное...):

Код: Выделить всё

x64 Stack overflow|0000000003495928	1	2019-05-07 22:48:53	1412	1181bca2
x64 Access violation at address 0000000005A16C99 in module 'ext.dll'. Read of address 000000000BB3ADC0|0000000005A16C99	1	2019-05-20 19:55:57	1412	
x64 Access violation at address 000000000B9B6C99 in module 'ext.dll'. Read of address 000000000BCDAB40|000000000B9B6C99	1	2019-05-20 19:56:09	1412	
x64 Access violation at address 0000000006F16C99 in module 'ext.dll'. Read of address 0000000007EFAB40|0000000006F16C99	1	2019-06-07 22:38:58	1417	
x64 Stack overflow|000000000FA00378	1	2019-07-11 18:25:20	1425	118495bd
x64 Access violation at address 0000000000C6FFB2 in module 'UnrealCommander64.exe'. Write of address 0000000000050000|0000000012DFC7F8	1	2019-07-11 18:27:16	1425	27309290
x64 Stack overflow|000000000A440768	1	2019-07-11 18:29:45	1425	f0c611b0
x64 Access violation at address 0000000000C6FFB2 in module 'UnrealCommander64.exe'. Write of address 0000000000050000|000000000A443358	1	2019-07-11 18:35:33	1425	400fb148
x64 Stack overflow|000000000DA2DAE8	1	2019-07-11 18:41:48	1425	79868fdc
x64 Access violation at address 00000000050B6C99 in module 'ext.dll'. Read of address 000000000523AB40|00000000050B6C99	1	2019-07-12 11:57:46	1425	
x64 Access violation at address 000000000089E795 in module 'UnrealCommander64.exe'. Read of address FFFFFFFFFFFFFFFF|000000000089E795	1	2019-07-12 11:57:46	1425	
x64 Access violation at address 0000000006E46C99 in module 'ext.dll'. Read of address 000000000BD6AB40|0000000006E46C99	1	2019-07-24 16:13:09	1425	
x64 Access violation at address 0000000006E46C99 in module 'ext.dll'. Read of address 0000000009DDAB40|0000000006E46C99	1	2019-07-24 16:13:09	1425	
x64 Access violation at address 0000000008E2569A in module 'ext.dll'. Read of address 0000000000000008|0000000008E2569A	1	2019-09-09 20:25:13	1425	
x64 Access violation at address 0000000005886C99 in module 'ext.dll'. Read of address 0000000008A9AB40|0000000005886C99	1	2019-09-09 20:26:21	1425	
x64 Access violation at address 0000000005AB7239 in module 'ext.dll'. Read of address 00000000096CAB40|0000000005AB7239	1	2019-10-11 15:15:41	1431	
x64 List index out of bounds (-1)|0000000003412C38	1	2019-11-22 02:32:37	1437	ab7f8134
x64 List index out of bounds (-1)|000000000C62EDD8	1	2019-11-28 16:07:16	1437	4b267ce8
x64 Access violation at address 0000000005A35B94 in module 'ext.dll'. Read of address 0000000000000008|0000000005A35B94	1	2019-12-05 15:55:55	1437	
x64 List index out of bounds (-1)|00000000035C4FD8	1	2019-12-11 03:43:44	1437	a9d940f9
x64 Access violation at address 0000000005A07239 in module 'ext.dll'. Read of address 000000000B83AB40|0000000005A07239	1	2020-01-26 20:58:31	1437	

Последняя строчка вроде совпадает по времени с моментом когда это системное сообщение об ошибке вылезло.