Max Diesel писал(а):
В такой ситуации программа при запуске получает удаленный ключ, он от старой версии, обновить его в удаленном каталоге она не имеет права.
Угу, это понятно.... Хотя когда я обновлял ключи при переходе на альфу - сначала всё равно запутался, и поведение мне снова показалось нелогичным. Я б сказал, что логичнее сделать диалог с вариантами типа:
- обновить удалённый ключ - старый файл будет переименован в "license_pre_2016-12-31.lic"
- забыть удалённый ключ и положить новый в папку пользовательских настроек UC
- забыть удалённый ключ и положить новый ключ в папку исполняемых файлов UC (могут потребоваться права администратора)
- оставить всё как есть (новый ключ появится в папке настроек пользователя, ключ в папке программы останется прежним, удалённый ключ останется прежним, и при следующем запуске снова скачается) (не рекомендуется)
Я правда так и не понял, почему вообще нельзя попытаться обновить (или дописать в ту же папку новый) ключ, если есть права на запись... Ну да ладно.
Max Diesel писал(а):
А вот почему окно "О программе" не появляется - это пока загадка, воспроизвести не получается.
Сейчас попробовал воспроизвести - тоже не получилось. Но точно было, систематически. Может с коннектом с сервером как-то связано (хотя почему одно "обновление" работает а другое - нет не очень понятно). Ну и ладно. Всё равно с обновлениями лицензии далеко не каждый день сталкиваешься.
Max Diesel писал(а):
К сожалению данная проблема отказалась проявляться при тестировании - за время удаления огромного количества файлов утечки памяти не появилось. Какой вид удаления использовался - в корзину, с диска, или WIPE?
Подробностей не помню уже.... Удалял, скорее всего, "с диска". Если ещё раз проявится - отпишусь. Но на данный момент я подозреваю, что я вообще мог перепутать причину - возможно память была занята данными "синхронизации каталогов".
Max Diesel писал(а):
2. в этом плане все так и предполагалось - в очередь задание попадает лишь тогда, когда известен его размер, соответственно если размер задания все еще подсчитывается, в очереди это задание не отображается.
Гм... ок, может это и не баг, но всё-таки очереди в первую очередь полезны именно когда операции будут длится достаточно долго. И "куча мелких файликов на уже загруженном другими операциями HDD" тут может быть одной из достаточно типичных ситуаций. А значит и "подсчёт размера задания" может занять достаточно долго.
Я даже пылался извращаться - создавал небольшую бессмысленную операцию в начале и ставил её на паузу, чтобы потом в неё добавить несколько последовательных операций с нужными мне данными. К сожалению, в очередь они попадают, видимо, именно в порядке "кто первым оценит объём задания" (что делает затею бессмысленной, и, ИМХО, не интуитивно).
Кстати, ИМХО, не хорошо, что такая операция вообще нигде не отображается, пока не посчитается размер задания - если начитаешь искать, то создаётся впечатление, что она просто пропала. Лишь надпись "копирование 100 КБ/с" меняется на "копирование 0 КБ/s, ???s)), а что уже добавил, а что нет - не видно.
Лично мне всё-таки представляется более логичным вообще немного другой вариант:
- Порядок операций задан пользователем и сам по себе не меняется (Тогда и в очередь можно добавлять до "оценки размера задания".)
- Собственно и сама "оценка размера задания" - такое же задание, и тоже должно выполняться последовательно с остальными операциями. И отображать её можно так же, в той же очереди...
- И вообще, всё должно происходить так, словно и нет никакой очереди, а просто пользователь каждый раз ждёт окончания заданной им операции перед тем как добавить новую. В таком случае можно строить операции типа
Код: Выделить всё
copy C:\temp\1\* D:\temp\1\
zip D:\temp\* E:\temp\x.zip
delete D\temp\*
- В идеале, для обеспечения атомарности всех операций, используемые пути должны "лочится" (вероятно, не через ОС, а в смыле некоторого внутреннего списка) - например, если пользователь создал описанную очередь, а затем вдруг, по ошибке, захотел создать другую очередь, в которой хочет уже сейчас удалить "D:\temp" - должно выскакивать предупреждение о невозможности параллельного выполнения таких операций.
Но это всё так, мечты
Кстати.... А "КБ/s" а не "КБ/с" - это специально?
Max Diesel писал(а):
3. судя по всему речь идет о ситуации, когда первое задание подсчитывает свой размер, а в это время добавлено второе, после чего произведена попытка отменить подсчет первого задания. В этой ситуации действительно подсчет не отменится. Мне никогда не встречалось этой ситуации до этого момента, предположительно со следующего билда будет корректно, благодарю за эту полезную информацию.
Эм... возможно
Я уже точно не помню всех обстоятельств, но напарывался достаточно часто. Если после починки этого момента всё ещё будет проявлсять - я просто опять отпишусь...
Max Diesel писал(а):
Вообще-то в этом диалоге обычно отображается каталог, в который запрещен доступ. Какие именно действия приводят к появлению диалога, в котором проблемный каталог не указан?
Этого я и сам тогда не понял. Я тогда запускал много разных длительных операций... Некоторые упали. Нарочно воспроизвести не знаю как... Могу предположить только, что возможно, например, я ошибся, и поставил два UC удалять одну и ту же папку. Постараюсь понять, в чём могло быть дело, если ещё увижу.
Max Diesel писал(а):
Действительно, в программе нет расчета на то, что кто-то будет синхронизировать каталоги с двумя миллионами файлов. На каждый копируемый справа налево или слева направо файл программа создает отдельную запись, в которой кроме имени файла и его размера есть заодно и путь к этому файлу... соответственно если пути длинные, то при 2,5 миллионах файлов получится около 2,5 миллионов записей, каждая из которых занимает до нескольких килобайтов памяти. Как следствие, получается очень много занятой памяти. Ну и при попытке выполнить синхронизацию программа все эти 2,5 миллиона записей перебрасывает в одну гигантскую очередь копирования. Для каталогов адекватного размера это незаметно, так как очередь длиной в 10-20 тысяч операций - это нормально, но очередь в 2,5 миллиона - в глазах программы это нечто из области фантастики. К сожалению у меня пока нет идей относительного того, как можно изменить код чтобы 2,5 миллиона записей в очередь копирования добавлялись быстро и занимали мало памяти.
Гм... может быть мы всё-таки не совсем верно поняли друг друга.....
- ИМХО, одной из целей перехода к x64 обычно как раз ставят резкое смягчение ограничений на количество всяких разных объектов во всяких разных массивах....
- Если ограничение на количество объектов всё-таки превышено - полезно всё-таки как-то показавать ошибку....
- Я ничего не имею против того, что UC потребляет ~3ГБ RAM для сравнения папок с ~2.5М файлов... ИМХО, примерно 1КБ на файл это вполне адекватно.
- Если при этом для очереди требудется более 60ГБ - это немного странно. Данные-то, казалось-бы, те же самые. Но мне показалось, что дело не в потреблении памяти, а в том, что оно где-то зациклилось - оно два дня висело, а обычно за пару секунд создаёт очередь. Может быть там всё-же где-то какой-то индекс недостаточной разрядности/указатель остался 32-битный или что-то вроде того?