> Файловая система всегда знает что в файле есть (или должно быть) в данный момент. только в вашей фантазии. А в реальности у ФС есть куча кешей в волатильной памяти над которыми она не имеет контроля. Есть обстоятельства не подконтрольные ФС в виде форсмажоров. Т.е. знать то она может, но легко это забывает.
> Пока что я вижу дичайшие костыли - тем кому надо *надежно* писать в файлы почему-то зверски извращаются с воркэраундами: запись в темповый файл нового файла, удаление старого файла, ренейм темпа в старого файла.
вы не доконца понимаете зачем это нужно. На всякий случай поясню: пока процесс занимается модификацией данных файла он может быть нужен другим процессам. Чтобы все остальные не ждали когда же наконец произойдут изменения, делается такой финт. Это реализация простой версионности через файлы и только второй по важности эффект от неё заключается в согласованности данных.
Для обеспечения консистентности используют совершенно другие приёмы - принудительные fsync() и т.п.
Т.е. я вам гарантирую на % 99.9, что при любой позикс ФС такие приложения будут делать ровно тоже самое. И это связано с журналированием данных и CoW только на второстепенных планах.
> Потому что если там просто писать файл и в этот момент все накроется, файл будет наполовину перезаписан.
В любой ФС с позикс интерфейсом он будет именно так недозаписан.
> СУБД сами во многом файловые системы напоминают, особенно в части журналирования.
Скорее наоборот, фс со своими зачаточными журналами и CoW напоминают ACID СУБД.
> Но вообще-то, когда прикладухам приходится морочиться с журналингом самолично потому что файловая система дескать не может журналить быстро и честно одновременно - это жуткий изврат.
ещё раз попробую донести очевидную мысль - позиксная ФС _не_ может предложить приложению достаточный функционал журналирования.
Бывают не позиксные специальные ФС с таким функционалом.
