Открываем файл,

[tengiz]

А может так: при открытии файла создаем hardlink...

Good. Very good. Very brilliant idea. Будем щупать. Thanks.

А разве VC не именно это и предлагал?

[A. Fig Lee]

А может так: при открытии файла создаем hardlink...

Good. Very good. Very brilliant idea. Будем щупать. Thanks.

А разве VC не именно это и предлагал?

нет. не совсем. Такие мысли у меня в голове тоже крутились, но хардлинк в голову не пришел.

[Strannik223]

Так hardlink == link()
А на FreeBSD есть chflags, который позволяет запретить удаление файла. Даже рутом пока обратно флаг не поставиш файл не удалишь. На солярке такого нет?

[vc]

А может так: при открытии файла создаем hardlink...

Good. Very good. Very brilliant idea. Будем щупать. Thanks.

А разве VC не именно это и предлагал?

нет. не совсем. Такие мысли у меня в голове тоже крутились, но хардлинк в голову не пришел.

Actually, what I suggested earlier was indeed a hardlink. I could not care less who offered what and in what specific order, but perhapse the OP does not know what a hardlink is. So for educational purposes, here's the code again:

Code: Select all

#include <unistd.h> 
#include <fcntl.h> 
#include <errno.h> 

int main() { 
  if (link("a.dat", "a.dat.bck") == -1)  /* <- This is a hardlink */
    {printf("Could not create a backup name: %d\n", errno); exit(2);} 
  sleep(10); 
  if (rename("a.dat.bck", "a.dat") == -1) { 
    if (errno == EEXIST) unlink("a.dat.bck"); 
    else printf("Error renaming : %d\n", errno); 
  } 
} 

You know, that Stevens's book is mighty good ...

VC

[f_evgeny]

А может так: при открытии файла создаем hardlink с каки нибудь "мусорным названием" а при закрытии проверяем, если орининал не был удален шаловливыми ручками то удаляем hardlink а если наш файл убили, то переименовываем hardlinked file to original name. Только надо бы предусмотреть зачистку hardlink-ов которые остаются в результате крешей.
Правда остается возможной диверсия: кто то удалил файл и создал новый с таким же именем.

Вот, это наверное решение на поставленный вопрос. Вт только ИМХО, вопрос поставлен кривовато и так решать хотя и возможно, но на мой взгляд немного некошерно.
Хотя информации немного недостаточно, но я могу себе представить три ситуации и три способа решения данной задачи:
1. Пользовательская программа пишет в файл пользователя в директории пользователя. Удалить никто не может, кроме пользователя или root-а. Защищаться надо от самого пользователя. Защита - резервные копии, ну или, как предложено, хардлинки. Но, хардлинки не будут работать на некоторых ФС и на разных партишенах.
2. Демон пишет данные в свой файл.

An application (or a group of inter-related applications) must use a subdirectory of /var/lib for its data.

Тогда файл находится в директории /var/<имя демона> или /usr/local/var/<имя демона>
Про пермишены у меня в debian-policy написано, что директории должны быть 755 (c правом записи только для пользователя) или c 2755 с правом записи для группы.
Нужна защита от пользователя. При указанном расположении файлов и директориев проблема случайного удаления пользователем не возникает - у пользователя (в том числе и у других демонов не хватает прав).
3. Демон или программа пользователя пишет данные в лог, через демона записи в лог. Нужна защита от злоумышленника (в том чисме и с правами root-а). В общем случае проблема решается только записью логов на специально выделенном компьютере. Демон записи в лог это умеет.
Ссылки по теме - Filesystem Hierarchy Standard http://www.pathname.com/fhs/pub/fhs-2.3.html (Для Линукса)

[f_evgeny]

Злостный оффтопик.
....
Юмор, конечно, понятен - а что за копирайт на шутку N 21?

Это детский анекдот про заключенных, которые долго сидели в одной камере и вместо того, чтобы рассказывали анекдоты, просто называли их номера.
А такая терминология довольно широко распространена и привычна среди русскоязычных линуксоидов.
Ну, например, если принято решение делать что-то так, а не иначе и сего момента считать что вот этот путь правильный, а остальные - нет, то это называют "Генеральной линией". Ну и так далее.

[A. Fig Lee]

Actually, what I suggested earlier was indeed a hardlink. I could not care less who offered what and in what specific order, but perhapse the OP does not know what a hardlink is. So for educational purposes, here's the code again:

Code: Select all

#include <unistd.h> 
#include <fcntl.h> 
#include <errno.h> 

....

You know, that Stevens's book is mighty good ...

VC

Во-во. Именно код для едюкейшнел пюрпосес я пропускаю, не читая. Нет смысла, зачем писать программу если все можно через шелл?
Я прочитал идею и подумал о димоне который увеличивал бы каунтер открытого файла и проверял директори ентри.

[A. Fig Lee]

Вот, это наверное решение на поставленный вопрос. Вт только ИМХО, вопрос поставлен кривовато и так решать хотя и возможно, но на мой взгляд немного некошерно.

Muzhiki! Vy zabodali uzhe! Povtorjaju op'jat': dimon, Solaris 8 (mozhet Linux Red Hat) - pishet chasto i mnogo v fajl. Fajl v etot moment ktoto vzjal i udalil.

[f_evgeny]

Вот, это наверное решение на поставленный вопрос. Вт только ИМХО, вопрос поставлен кривовато и так решать хотя и возможно, но на мой взгляд немного некошерно.

Muzhiki! Vy zabodali uzhe! Povtorjaju op'jat': dimon, Solaris 8 (mozhet Linux Red Hat) - pishet chasto i mnogo v fajl. Fajl v etot moment ktoto vzjal i udalil.

Зачем же так волноваться?
Вы вправе делать то, что хотите. Но ситуация неправильная.
Такие ситуации бывают только в военное время, когда снаряд попадает в голову. Интересен контекст, в котором у демона, который пишет файл, кто-то берет его и удаляет.

[Strannik223]

Actually, what I suggested earlier was indeed a hardlink. I could not care less who offered what and in what specific order, but perhapse the OP does not know what a hardlink is. So for educational purposes, here's the code again:

vc, вы были однозначно первым, но я объяснил доступнее

[A. Fig Lee]

Вот, это наверное решение на поставленный вопрос. Вт только ИМХО, вопрос поставлен кривовато и так решать хотя и возможно, но на мой взгляд немного некошерно.

Muzhiki! Vy zabodali uzhe! Povtorjaju op'jat': dimon, Solaris 8 (mozhet Linux Red Hat) - pishet chasto i mnogo v fajl. Fajl v etot moment ktoto vzjal i udalil.

Зачем же так волноваться?

Так евгений, Вы б почитали скоко раз я пересказывал содержание. На 4-й раз всегда положено волноватся. В Унихах всегда так.

Вы вправе делать то, что хотите. Но ситуация неправильная.
Такие ситуации бывают только в военное время, когда снаряд попадает в голову. Интересен контекст, в котором у демона, который пишет файл, кто-то берет его и удаляет.

Well. Стоять то будет не у нас. Может и за океаном. Че там за жизнь и порядки - неизвестно. Приказано - сделать так, значит надо делать. Ну не скажу ж я менегеру - "ты там проследи, чтоб идиотов к компьютеру не подпускали и все будет ок".

[A. Fig Lee]

Да, мужики, did I say thanks?
Спасибо всем.

[f_evgeny]

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

Да я так и думал, что выбирать способ решения не получается. Но, ведь Вам нужно решить проблему, а нам (остальным) еще и пообщаться.
Кстати, в порядке светской беседы, сейчас, в связи с массовым приходом разработчиков из Windows в UNIX, они тащат с собой и свои подходы и решения.
К примеру в fido7.ru.linux одна из самых типовых ситуаций, когда спрашивают: Как мне сделать X? В процессе обсуждения выясняется, что вообще-то в UNIX такой вопрос не корректен, так как проблема решается вообще другим путем, при котором вопрос X вообще не возникает.
А возникают совсем другие вопросы.

[f_evgeny]

Прекрасно. Вернемся к оригинальному вопросу - как выловить что файл был "rm-ed"?
Единственно приходит в голову - периодически чекать директори ентри.

Какой кошмар, ну прямо каменный век какой-то! А вот в Windows есть замечательная фунция ReadDirectoryChangesW, которая сама все изменения рапортует. В юниксе наверняка есть что-то подобное.

Вот вроде всем ясно как удаляется файл в Юниксе. А как делается то же самое в виндовс? С точки зрения пользователя иногда надо удалить файл, который открыт другим приложением. Как разруливается в Виндовс такая ситуация?

[lx_uk]

Вот вроде всем ясно как удаляется файл в Юниксе. А как делается то же самое в виндовс? С точки зрения пользователя иногда надо удалить файл, который открыт другим приложением. Как разруливается в Виндовс такая ситуация?

В Windows если при открытии файла не указан флаг FILE_SHARE_DELETE (а обычно оно так и есть) то открытый файл лочиться и система не даст его удалить. Удалить его можно во время следующей перезагрузки с помощью MoveFileEx, например.

Но вообще в Windows этикет тот же что и в Unix. Если файл залочен - не тебе его удалять. Если же ты администратор - то сам будешь виноват если удалишь нужный файл.

[f_evgeny]

Вот вроде всем ясно как удаляется файл в Юниксе. А как делается то же самое в виндовс? С точки зрения пользователя иногда надо удалить файл, который открыт другим приложением. Как разруливается в Виндовс такая ситуация?

В Windows если при открытии файла не указан флаг FILE_SHARE_DELETE (а обычно оно так и есть) то открытый файл лочиться и система не даст его удалить. Удалить его можно во время следующей перезагрузки с помощью MoveFileEx, например.

Но вообще в Windows этикет тот же что и в Unix. Если файл залочен - не тебе его удалять. Если же ты администратор - то сам будешь виноват если удалишь нужный файл.

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

[tengiz]

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

Переведите на русский, pls?

[f_evgeny]

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

Переведите на русский, pls?

1. В первом приближении, удалить файл в UNIX может любой, у кого есть права на запись на директорий, в котором находится файл.
2. Я никогда не видел/слышал о документе (для виндовс), в котором было бы написано (с похожей например на FHS -file hierarhy standard для Линукса), какие файлы (по функциональному назначению) где должны находится в файловой иерархии. Возможно я ошибаюсь.

[lx_uk]

2. Я никогда не видел/слышал о документе (для виндовс), в котором было бы написано (с похожей например на FHS -file hierarhy standard для Линукса), какие файлы (по функциональному назначению) где должны находится в файловой иерархии. Возможно я ошибаюсь.

Я бы сказал что подобные требования описываются в различных "Designed for Microsoft Windows NT/2000/XP/etc Logo Program Requirements".

<added>
http://www.microsoft.com/winlogo/softwa ... loads.mspx
</added>

[Strannik223]

Я бы сказал что подобные требования описываются в различных "Designed for Microsoft Windows NT/2000/XP/etc Logo Program Requirements".

Требования есть, порядка нету. System32 наглядное тому потверждение. Это даже не безпорядок, это хаос какой то. И dll и exe, битмапы, логи, ресурсы, все что только можно там лежит большой кучей.
Одним из преимуществ организации файлов на Юнихе является то что файлы опрерационки и софта проинсталираваного самостоятательно лежат в разный директориях что делает возможным на порядки более простой апгрейд операционки. Инсталятор подразумевает что все что лежит в директориях опрерационки может быть безопасно удалено.
Убивает мерзкая привычка винды при запуске файла (exe or dll) лочить его. Из за этого до сих пор добрая половина инсталяторов програм требует знаменитого reboot.

В моей практике был случай когда я апгрейдил Юникс который в другом городе стоял. Причем апгрейд был тяжелый, менялся формат executable. На винде о таком и мечтать запрещено.

[lx_uk]

Я бы сказал что подобные требования описываются в различных "Designed for Microsoft Windows NT/2000/XP/etc Logo Program Requirements".

Требования есть, порядка нету. System32 наглядное тому потверждение. Это даже не безпорядок, это хаос какой то. И dll и exe, битмапы, логи, ресурсы, все что только можно там лежит большой кучей.

Совершенно верно.

Одним из преимуществ организации файлов на Юнихе является то что файлы опрерационки и софта проинсталираваного самостоятательно лежат в разный директориях что делает возможным на порядки более простой апгрейд операционки. Инсталятор подразумевает что все что лежит в директориях опрерационки может быть безопасно удалено.

Да. А что, кто-то возражает? Ну тогда это трудности возражающего.

Убивает мерзкая привычка винды при запуске файла (exe or dll) лочить его. Из за этого до сих пор добрая половина инсталяторов програм требует знаменитого reboot.

Что-то мне подсказывает, что ноги тут растут из FAT. Неудобно. А что делать? Было бы неплохо, чтобы с появлением NTFS эта проблема ушла бы в прошлое. Но в MS, видимо, считают это идеологически правильным.

Кстати, кто может прокомментировать технические сложности с удалением залоченного файла? Ведь на самом деле речь идет только об удалении записи из директории?

В моей практике был случай когда я апгрейдил Юникс который в другом городе стоял. Причем апгрейд был тяжелый, менялся формат executable. На винде о таком и мечтать запрещено.

Ну и что. Windows это-го не умеет. Какой толк повторять банальности?

PS. Хотя шаги предпринимаются. Все меньше critical patches с windowsupdate требуют перезагрузки, например.

[tengiz]

...Убивает мерзкая привычка винды при запуске файла (exe or dll) лочить его. Из за этого до сих пор добрая половина инсталяторов програм требует знаменитого reboot.

В моей практике был случай когда я апгрейдил Юникс который в другом городе стоял. Причем апгрейд был тяжелый, менялся формат executable. На винде о таком и мечтать запрещено.

Причина этой привычки - двоичный файл является одновременно собственным файлом подкачки для кода/констант, поэтому его менять нельзя. Однако его по умолчанию можно переименовывать "на ходу". Откуда следует, что Ваш тяжёлый upgrade элементарно делается именно таким нехитрым способом - переимеровать исполняющийся exe/dll, затем записать новый с тем же именем куда нужно. При следующем запуске будет уже работать новый файл.

[tengiz]

1. В первом приближении, удалить файл в UNIX может любой, у кого есть права на запись на директорий, в котором находится файл.

OK, теперь понятно, что речь шла о UNIX. В Windows (как и во многих других ОС) имеется mandatory file locking - при открытии файла можно указать режимы блокирования, которые затем никем не могут быть игнорированы, в отличие от классического UNIX. Т.е. дополнительные препятствия для удаления/изменения сордержимого файлов кроме прав на файл и на директорию - это наличие активных процессов, открывших этот файл и специально попросивших его не трогать.

[lx_uk]

Причина этой привычки - двоичный файл является одновременно собственным файлом подкачки для кода/констант, поэтому его менять нельзя. Однако его по умолчанию можно переименовывать "на ходу". Откуда следует, что Ваш тяжёлый upgrade элементарно делается именно таким нехитрым способом - переимеровать исполняющийся exe/dll, затем записать новый с тем же именем куда нужно. При следующем запуске будет уже работать новый файл.

Тенгиз, а почему залоченный файл обязательно должен быть связан с элементом директории? Так что в результате файл можно переименовать но не удалить. Это особенности файловой системы (т.е. нечто "фундаментальное") или конкретной реализации?

[f_evgeny]

1. В первом приближении, удалить файл в UNIX может любой, у кого есть права на запись на директорий, в котором находится файл.

OK, теперь понятно, что речь шла о UNIX. В Windows (как и во многих других ОС) имеется mandatory file locking - при открытии файла можно указать режимы блокирования, которые затем никем не могут быть игнорированы, в отличие от классического UNIX. Т.е. дополнительные препятствия для удаления/изменения сордержимого файлов кроме прав на файл и на директорию - это наличие активных процессов, открывших этот файл и специально попросивших его не трогать.

Я не говорю плохо это, или хорошо, но, лично для меня из этого следует то, что многие вещи, которые в Юниксе реализуются на скриптах, в Виндовсе работать не будут. Или для того, чтобы они работали надо перезапускать компьютер.