-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Всем неравнодушным, доброе утро.
Следующий *тест*.
doc с 13 jpg файлами с общим весом 48,8 МБ, свойства документа и сам документ открываются около минуты.
что делаю: сохраняю все файлы на локал, меняю расширение с jpg на bmp, перевкладываю файлы обратно, и ....барабанная дробь, doc открывается влет.
Следующий *тест*.
doc с 13 jpg файлами с общим весом 48,8 МБ, свойства документа и сам документ открываются около минуты.
что делаю: сохраняю все файлы на локал, меняю расширение с jpg на bmp, перевкладываю файлы обратно, и ....барабанная дробь, doc открывается влет.
теже файлы на локале, меняю расширение с bmp на jpg, перевкладываю файлы обратно, и ....барабанная дробь, doc открывается опять минуту.
создал копии документа
1 - документ с bmp файлами открыл\закрыл 4 раза.
2 - открытие документа с jpg файлами.
чудеса!
есть такая трабла - у тебя в статус баре еще пишется не помню как звучит что-то наподобие "рекомпресс картинко"
суть прикола в следующем бери любую кнопку-картинку(на форме) и установи ей НЕ 100% размер - она всегда будет рекомпресситься из-за такого прикола
Опция не включена.В св-вах базы часом не включена опция "Display images after loading"?
При открытии копий документов, при просмотре свойств копий документов в статус баре ни чего не пишется, кроме *1 document selected*.
Вспомнил! Где-то на интертрастовском форуме была тема со сравнением сжатия (LZ1) файлов картинок, так вот jpg-файлы, хоть они изначально и меньше, но в итоге при сжатии занимают больше места, чем bmp, т.к. LZ1 Domino оптимизирован как раз для bmp. Потестил, действительно оказалось так, ну или наравне. С тех пор jpeg'и стараюсь не вкладывать.
susinmn, спасибо!
susinmn, спасибо!
Если вопрос не решен, можно ли выгрузку двух доков с разными вложениями увидеть в xml?
Первый быстро открывающийся, а второй медленно. Больше интересует поле $FILE.
Параметры хотел глянуть:
<item name='$FILE' summary='true' sign='true' seal='true'><object><file hosttype='msdos' compression='none' flags='storedindoc' encoding='none' name='Новый текстовый документ.txt' size='295' storagesize='190' desiredcompression='lz1'>
Первый быстро открывающийся, а второй медленно. Больше интересует поле $FILE.
Параметры хотел глянуть:
<item name='$FILE' summary='true' sign='true' seal='true'><object><file hosttype='msdos' compression='none' flags='storedindoc' encoding='none' name='Новый текстовый документ.txt' size='295' storagesize='190' desiredcompression='lz1'>
Последнее редактирование модератором:
Теперь и у меня похожая история. Зашёл сегодня в свою БЗ, в которой, вроде как, ещё несколько дней назад всё цвело и пахло.
В поле полнотекстового поиска во вьюхе ввёл @, поискал. Открываю один из документов, в котором 2 pdf'ника, nSERVER.exe (а сервер у меня стоит на этом же компе) загружает проц на 100%, потом через секунд 20 его отпускает и клиент выдаёт сообщение: "Server Error: Memory allocation request exceeded 65,000 bytes".
В консоли сервера ничего.
После попытки повторного открытия думал где-то секунд 10, но открыл документ.
Открываю другой документ, в котором 1 pdf, всё также виснет, клиент возвращает такое сообщение: "The full text index for this database is corrupted. Delete and recreate the full text index."
На консоли сервера появилось:
Удаляю у БД FT-индексы, создаю заново, при этом NUpdate.exe уходит в 100% и сервер для каждого вложения выдаёт такую запись:
[1174:0005-0D04] 21.12.2012 12:37:05 Processing only first 6291456 bytes of attachment <имя атачмента>.
Дождавшись окончания создания индексов (на сервере об этом нет упоминания, просто с NUpdate.exe полностью сбросилась нагрузка) и подождав ещё несколько минут, захожу в базу, нахожу док в виде (не по FT-поиску, а вручную), открываю, всё отлично - открывается за долю секунды.
Повторяю весь тест сначала: поиск по "@", открытие того же дока - такие же тупняки клиента и сервера с первой ошибкой; 2-я ошибка уже не выдаётся, - сервер тупит, но доки в конце-концов открывает.
Жму "Clear results...", сбрасывая результаты поиска, снова открываю тот же док, отыскав его вручную, - прекрасно открывает.
Сделал базе FixUp - ошибок 0, но не помогло, всё то же самое, как и на предыдущей итерации теста.
Итого: проблема при открытии документов с вложениями из результатов FT-поиска.
В поле полнотекстового поиска во вьюхе ввёл @, поискал. Открываю один из документов, в котором 2 pdf'ника, nSERVER.exe (а сервер у меня стоит на этом же компе) загружает проц на 100%, потом через секунд 20 его отпускает и клиент выдаёт сообщение: "Server Error: Memory allocation request exceeded 65,000 bytes".
В консоли сервера ничего.
После попытки повторного открытия думал где-то секунд 10, но открыл документ.
Открываю другой документ, в котором 1 pdf, всё также виснет, клиент возвращает такое сообщение: "The full text index for this database is corrupted. Delete and recreate the full text index."
На консоли сервера появилось:
Открытие некоторых документов без вложения дают такую же ошибку в клиенте; на сервере, естественно, ничего, т.к. документы без вложений.
Удаляю у БД FT-индексы, создаю заново, при этом NUpdate.exe уходит в 100% и сервер для каждого вложения выдаёт такую запись:
[1174:0005-0D04] 21.12.2012 12:37:05 Processing only first 6291456 bytes of attachment <имя атачмента>.
Дождавшись окончания создания индексов (на сервере об этом нет упоминания, просто с NUpdate.exe полностью сбросилась нагрузка) и подождав ещё несколько минут, захожу в базу, нахожу док в виде (не по FT-поиску, а вручную), открываю, всё отлично - открывается за долю секунды.
Повторяю весь тест сначала: поиск по "@", открытие того же дока - такие же тупняки клиента и сервера с первой ошибкой; 2-я ошибка уже не выдаётся, - сервер тупит, но доки в конце-концов открывает.
Жму "Clear results...", сбрасывая результаты поиска, снова открываю тот же док, отыскав его вручную, - прекрасно открывает.
Сделал базе FixUp - ошибок 0, но не помогло, всё то же самое, как и на предыдущей итерации теста.
Итого: проблема при открытии документов с вложениями из результатов FT-поиска.
Последнее редактирование:
Ну есть такая трабла, если много результатов поиска (в одном документе, то что подсвечивает система).
Попробуйте в хелпе найти документ в котором много раз упоминается искомое слова (например the), увидите тормоза...
1-й файл того дока = 2.37Mb, 2-й = 6.18.
Кстати, да! Попробовал на других файлах (htm, zip, exe, dll) - всё нормально. Такой баг только на pdf.
Нет. Это где-то в АК сервера настраивается?
не, как всегда такие вкусные плюшки прячутся в инишках
FT_Index_Ignore_Attachment_Types=*.nsf,*.ntf,*.tif,*.sys,*.pag,*.img,*.wav,*.gif
,*.jpg,*.dll,*.tar,*.exe,*.zip,*.au,*.mpg,*.mov,*.mp3,*.cca,*.dbd,*.p7m,*.p7s,*.w
pl,*.bmp,*.rar
...Processing only first 6291456 bytes of attachment <имя атачмента>.
Это в ини же регулируется - не?
Возможно. В своём серверном notes.ini ничего похожего не нашёл.
Но даже если бы и нашёл, то всё равно, что с этим делать? Установить больше? Так всё равно возможна ситуация, когда вложение превысит установленный размер.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!