proNovell

7-11-2002 5:01:53 am: FILESYS-5.2-244
Severity = 2 Locus = 2 Class = 20
Insufficient disk space on volume BEST prevented a newly decompressed file from being commited to disk in its decompressed format when the file was closed.

Что-то я не могу въехать в суть проблемы :
Места на данном томе еще 360 метров, хранятся только запускаемые файлы БЕСТА, его базы хранятся на другом томе.
Если кто-то чем-то может помочь, прошу кидайте варианты.....или возможные причины.

надо понять, при обращении к какому файлосу это сообщение вылезает. Скорее всего, там есть такой большой файл (в некомпресованном состоянии), может быть по размеру большой, а внутри пустой. Вариантов м.б. много.

Обычно такое возникает, когда идет интенсивное удаление файлов в каталогах с неусстановленным флагом "Очищать немедленно".

Если у Вас установлен клиент Novell, то информацию можно получить в проводнике высветив свойства тома и выбрав закладку статистика.
Там можно увидеть сколько у Вас свободного и очижаемого пространства на томе.

Если очищаемого пространства много - в контекстном меню тома есть пункт "Очистить файлы" (это то ,что скорее всего Вам нужно). Смело очищаейте с подкаталогами. Можно выбрать очистку части тома, встав на тот каталог, который Вы хоттите очистить.

ПРИ ОЧИСТКЕ СТИРАЮТСЯ ОКОНЧАТЕЛЬНО УЖЕ УДАЛЕННЫЕ ФАЙЛЫ - ВОССТАНОВЛЕНИЕ ИХ БУДЕТ НЕВОЗМОЖНО.

Очистку сделал, не помогло.....освободилось максимум метра 4, чьл не есть хорошо

Как бы выявить возможный файл ?


Что-то еще? Да и данная проблема может влиять на скорость в сети ?

This message means that a file was decompressed and opened. The file is then modified in some way and then attempted to be written back to disk in its decompressed format.

This message is occurring because of one of (or both) the following conditions.

1. The system does not have enough space left on the volume to save the file in its decompressed format.
2. The file was opened by a user that has disk space limitations and by saving the file in its decompressed format it puts the user over the space limitation.

The customer can free up disk space and or check space limitations for users to resolve this.

Стоит проверить 2-й вариант. Влиять сильно не должно ( хотя от размера файла зависит ) - разве что файл будет каждый декомпрессироваться ( в принципе, на некоторых системах, может давать небольшую задержку ).

Как выявить - можно попробовать в MONITOR'е открыть коннекшн подозрительного юзера и смотреть за его открывающимися файлами.

Можно еще попробовать установить у всех тех файлов атрибут, запрещающий их компрессию ( у меня была подобная ситуация, когда дешевле всего было поступить именно так ).

Ничего страшного в этом нет. На томе действительно у Тебя видимо мало места или юзерские квоты не позволяют сохранить новеллу ранее сжатый файл в разжатом виде. Подумай что можно перенести или удалить. Можно встать на корневой каталог на этом томе и сделать PURGE *.* /a Это окончательно удалит удаленные файлы :0).
На работе системы это никак не сказывается - разве что ей приходится все время разжимать :0) этот файл когда юзер его открывает. К сожалению я не знаю как определить имя этого файла.

К сожалению я не знаю как определить имя этого файла.

Я открывал коннекшн юзера в MONITOR'e ( разумеется, сначала надо отловить ситуацию, когда соответствующее сообщение вылезает ) и смотрел за открывающимися файлами. Ну а дальше анализируя атрибуты у них ..