Что произойдет, если одна программа пишет файл, а в это же время другая программа пытается его читать?

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

б). Ошибки не будет, но система приостановит вторую программу до окончания записи и закрытия файла первой программой;

в). Вторая программа не увидит файла и выдаст ошибку "Файл не найден";

г). Вторая программа выдаст ошибку "Нет прав";

д). Вторая программа выдаст ошибку совместного доступа;

е). Еще что-то (что именно?).

Причем здесь убунту? От программ зависит. tail -f же может читать файл, в который кто-то пишет, значит а) как минимум.

Забавно ещё то, что в Линукс удаление файла не мешает продолжать работать с ним.

А Юниксах доступ принципиально отличается от Виндоус?

cat /var/log/syslog

даст исчерпывающий ответ на все вопросы.

Пункт А.
Если за лочить, то пункт Г может быть Д.

В отличие от виндов в линуксе по умолчанию общий доступ разрешён. И файлы надо специально лочить есть api flock
или QT есть QLockFile

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

> И файлы надо специально лочить есть api flock

Возможность лочить зависит от файловой системы. На стандартной ext3/4 всё есть, а на распределённой lustre по умолчанию локов нет.

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

Б - есть такое.

> А Юниксах доступ принципиально отличается от Виндоус?

Принципиально нет, а вот справка такова, что голову сломать можно.

> Возможность лочить зависит от файловой системы. На стандартной
> ext3/4 всё есть, а на распределённой lustre по умолчанию
> локов нет.

Так локи через VFS работают им без разницы ext или lustre. Просто за абстракцию для VFS взят EXT3. Если ядро старое то да там локи работать не будут.

> Если ядро старое то да там локи работать не будут.

Не, там не в ядре дело. Там надо именно монтировать файловую систему с поддержкой локов. Как-то так:
flock  Enable full flock support, coherent across all client nodes.
localflock Enable  local  flock  support,  using  only  client-local  flock (faster,  for  applications that require flock but do not run on multiple nodes).
noflock Disable flock support entirely.  Applications calling flock will get an error.
http://manpages.ubuntu.com/manpages/precise/man8/mount.lustre.8.html
Но это специфика распределённой системы - нормальный полный лок на петабайтном томе с тысячами клиентских узлов будет тормозить безумно, поэтому без острой необходимости его включать никто не будет.

>>Если ядро старое то да там локи работать не будут.

Насколько старое должно быть ядро, если у тэннебаума описан эксклюзивный режим?
В 2+ уже точно была таблица блокировок.

>>В Юниксах доступ принципиально отличается от Виндоус?

Радикально разное внутреннее устройство.

> [9] tesseract ©   (13.10.17 14:39)
> Радикально разное внутреннее устройство.

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

Видимо, я совсем не понимаю.

> [10] Inovet ©   (13.10.17 14:59)
> при открытии файла

с определённым режимом доступа. Ещё и к разным кускам файла можно.