Вопрос: Определить, открыт ли файл


Я хочу создать скрипт bash, чтобы определить, открыт ли мой файл другим пользователем.

Я уже пробовал с lsof но это не сработало, как мне хотелось. Файлы могут иметь разные типы расширений, например. txt, pl, conf, cfg и т. д. Кто-нибудь может мне помочь?

У меня есть один сервер с большим файлом .conf. Если я пишу в одном файле, я не знаю, будет ли другой пользователь писать в том же файле. Поэтому я хотел бы создать сценарий, который позволит мне это знать.

Я попробовал что-то вроде этого lsof | grep MyFile или lsof /root/blabla/myfolder/myfile и т. д. Может быть, я не понимаю использования этого инструмента.

я постараюсь лучше объяснить мою проблему. Существует много пользователей, которые могут изменять файл .conf. Если два пользователя работают с одним и тем же файлом, последнее сохранение перезаписывает изменение, сделанное от другого пользователя. Мой скрипт хочет предупредить пользователей о том, что файл уже открыт другим пользователем и, возможно, открыть файл в режиме только для чтения. Я уже пробовал с ps aux (thx для подсказки), но я не могу оценить, был ли мой файл закрыт недавно.


1
2018-05-15 21:28


Источник


Пробовал sudo lsof | grep FileName? Может быть, grep -i будет лучше - Sergiy Kolodyazhnyy
В чем проблема, с которой вы сталкиваетесь? lsof ? - heemayl
«... но это не сработало, как мне хотелось».  Если вам нужна помощь, вы должны сказать нам (1), что вы хотите точно, и (2) как вы пытались использовать lsof и каким образом lsof «не работал». - John1024
И как вы использовали lsof ? Я имею в виду, что вы пробовали? - heemayl
ваш образец использования кажется мне правильным (помимо возможной проблемы с верхним и нижним регистром) ... не получаете ли вы желаемого результата? - heemayl


Ответы:


lsof точно перечисляет все открытые файлы.

«Проблема» заключается в том, что большинство редакторов открывают файл, читают содержимое (в ram) и закрывают файл.

Редакторы откроют файл при записи изменений.

Чтобы узнать, используют ли какие-либо редакторы файл, для всех пользователей, выполните

ps aux | grep file name

пример

Откройте файл test.file с nano в одном терминале.

В другом терминале выполняются следующие команды:

bodhi@daemon:~$sudo lsof | grep test.file
[sudo] password for bodhi: 

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.

Примечание: нет выхода;)

Теперь запустите ps aux

bodhi@daemon:~$sudo ps aux | grep test.file
bodhi     4736  0.0  0.0 121096  3404 pts/3    S+   17:49   0:00 nano test.file

Теперь мы видим нужную нам информацию;)

nano появляется, и мы редактируем test.file


1
2018-05-15 23:53



Следует отметить, что если другой файл был открыт из внутри редактор, то он не будет показан (оба через ps aux а также lsof). - saiarcot895
вероятно, лучше использовать контроль версий. - Panther


@ bodhi.zazen точно показал, что причина того, что ваши файлы не отображаются в выводе lsof.

Ну, так как нам не хватает описания вашего варианта использования, я предполагаю, что ваш скрипт

  • делает что-то, что требует времени
  • изменяет содержимое других файлов, которые могут быть изменены между моментом запуска вашего скрипта и временем, когда он готов изменить файл.

Если это так, вы можете сделать следующее:

  • получить контрольную сумму файла, который ваш скрипт намерен изменить раньше, например: sha1sum <file>
  • делать что-то много времени
  • проверьте текущую контрольную сумму вашего файла. Если это то же самое, что и раньше, оно не было изменено, если это не то же самое, вы можете принять решение и попросить пользователя сценария решить, следует ли перезаписывать или показывать diff и т. Д.

Это не идеально, и это просто выстрел в темноте, так как нам не хватает контекста, но, возможно, он вам будет полезен.


0
2018-05-16 00:11



на данный момент лучше всего начать использовать контроль версий;) - Panther
Разве ты не видел, как я съеживаюсь, когда писал? :) Это именно то, что я думал, когда я попросил использовать прецедент, так как прыгать через такие обручи, вероятно, можно полностью избежать. - Marcin Kaminski