Вопрос по истории C'шечки

write(2) бесполезен для _записи_ данные в файл - он просто передает их в кэш.

А вот это уже другой уровень абстракции, для программы write(2) — запись в файловый десткриптор. Ты придираешься к несущественному, ведь write(2) — просто системный вызов, «записать из буфера максимум n байт». Будет там файловая система, сокет или пайп — от вызывающей программы может и не зависеть. Как и наличие кэша. Для программиста достаточно убедиться, что вызов не вернул ошибки, а также знать, сколько было записано.

Имя им - «интерактивный редактор».

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

это максимум информативности, которого можно достичь на стадии, когда вызывается close.

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

Нужно проверять результат записи, когда еще известен контекст

А то ты не знаешь, какой файл и после записи чего закрываешь? Вот и сообщи это вместе с кодом ошибки, чтобы, во-первых, знать о событии, во-вторых, было с чего начинать исправления.

Ты придираешься к несущественному

Ну да, в главном-то ты прав - результаты операций ввода/вывода надо проверять. Правда, ты не понимаешь, что такое операция ввода/вывода, но это же несущественно.

write(2) — просто системный вызов, «записать из буфера максимум n байт». Будет там файловая система, сокет или пайп — от вызывающей программы может и не зависеть.

А совсем недавно этот же человек говорил о том, что результат записи может проверяться вычитыванием. Когда ты последний раз программы писал? Подозреваю, что это была та atoi, текст которой ты привел выше по треду.

то ты не знаешь, какой файл и после записи чего закрываешь? Вот и сообщи это вместе с кодом ошибки

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

Тогда расскажи, что именно.

Хех, выдать всё в терминал, пусть мышкой копипастит и кусками сохраняет.

...несмотря на то, что все три часа он нажимал Ctrl-S каждую минуту.

Вот из-за того, что слишком часто нажимал, в nilfs кончилось место. Но не беда, диплом всё ещё в памяти, а предыдущая версия — в файле на диске. Можно выбрать другой носитель для сохранения или запустить сборку мусора на текущем, а потом сохранить ещё раз.

Мы же про хорошие программы говорим, да?

ты не понимаешь, что такое операция ввода/вывода

Раскрой глаза.

А совсем недавно этот же человек говорил о том, что результат записи может проверяться вычитыванием.

Ты невнимателен. Мы уже договорились, что под записью подразумеваем write(2). Но так и не объяснил, почему считаешь проверку результата этого системного вызова «бесполезной».

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

И как ты это сделаешь, если проверять ошибку не считаешь нужным? :)

А совсем недавно этот же человек говорил о том, что результат записи может проверяться вычитыванием.

Ты невнимателен. Мы уже договорились, что под записью подразумеваем write(2). Но так и не объяснил, почему считаешь проверку результата этого системного вызова «бесполезной».

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

если проверять ошибку не считаешь нужным? :)

Но ведь я считаю нужным. «Поздравляем вас, гражданини, соврамши» (ц)

В те времена С'шникам было покласть на баги?

В те времена до компьютеров не добирались школьники и идиоты.

atoi предназначена для применения к входным данным, уже прошедшим этапы токенизации и валидации.

Ты невнимателен.

Я тебе уже один раз предложил уточнить термины, ты предпочел отморозиться: «Зачем? Вполне очевидно, что речь о write(2)». В этих рамках вызов ядра и есть запись в файл.

Для проверки записи в файл.

«Всё есть файл». С точки зрения приложения всё начинается и заканчивается дескриптором файла. Что там за ним: байты на диске, пайп или сокет — оно может и не знать. Происходящее в системе — другой уровень, но мы можем и о нём поговорить.

Но ведь я считаю нужным.

Тогда как понимать твоё «конечно, печально, но при ошибке закрытия уже поздно что-то делать», как не признание ненужности проверки? Особенно на фоне дальнейшего отстаивания именно этой точки зрения: «что именно (с ошибкой) делать?».

«Всё есть файл». С точки зрения приложения всё начинается и заканчивается дескриптором файла. Что там за ним: байты на диске, пайп или сокет — оно может и не знать.

После вот этого:

baka-kun> Что мы подразумеваем под «проверкой»: реакцию на ошибку или вычитку файла, «а вдруг не записалось». :)

тебе уже не стоит вилять про «всё есть файл», потому что понятно, что разговор шел о regular files.

Тогда как понимать твоё «конечно, печально, но при ошибке закрытия уже поздно что-то делать», как не признание ненужности проверки?

Как толстый намек на то, что записывать данные (записывать, а не вызывать write) нужно раньше, а close должен просто освобождать дескриптор.

После вот этого:

Этим я спросил, что ты подразумеваешь. И даже дал варианты ответа. Ты выбрал обсуждение в контексте write(2), а теперь виляешь хвостом. Нехорошо.

записывать данные нужно раньше, а close должен просто освобождать дескриптор.

То есть я ничего не наврал, и ты не считаешь нужным проверять ошибку close(2).

А метаданные по закрытию файла кто будет менять, Пушкин? А буферы и кеши сливать? Откуда ядру знать, что запись в файл была последняя, и надо бы закругляться? Предлагаешь новый вариант write_last(2) с семантикой close(2), но без освобождения дескриптора? Или каждый write(2) должен обрабатываться как последний? Наплевав на все оптимизации?

Этим я спросил, что ты подразумеваешь.

Этим ты продемонстрировал понимание, о чем идет речь.

А метаданные по закрытию файла кто будет менять, Пушкин?

fsync(2)

А буферы и кеши сливать?

fsync(2), fdatasync(2)

Откуда [...]

Предлагаешь [...]

Или [...]

Маны покури.

Продолжаешь вилять. Ну-ну.

А метаданные по закрытию файла кто будет менять, Пушкин?

fsync(2)

А ты обрабатываешь ошибки fsync(2)? Они возможны те же, что и у close(2), по тем же причинам. Помимо своих собственных. Правда сообщения у него менее информативные.

Кстати, ты действительно предлагаешь перед close(2) вызывать fsync(2)?

Маны покури.

Ты давай не мудри, ты пальцем покажи.

Продолжаешь вилять. Ну-ну.

Не рефлексируй.

Кстати, ты действительно предлагаешь перед close(2) вызывать fsync(2)?

Я предлагаю вызывать fsync для того, чтобы данные действительно записались, как и написано в его мане. И да, обрабатывать его ошибки.

Я предлагаю вызывать fsync для того, чтобы данные действительно записались

Хм...

Не рефлексируй.

А ты не уклоняйся в стороны от вопроса. :)

Я предлагаю вызывать fsync для того, чтобы данные действительно записались, как и написано в его мане. И да, обрабатывать его ошибки.

Чтобы указать системе слить всё на физический носитель прямо сейчас, если это необходимо. Всё правильно, именно так и нужно. В этом мы согласились. И ошибки close нужно обрабатывать по той же причине. Даже несмотря на успешный fsync перед ним, close может завершиться неудачно, и гарантии сохранности данных нет.

Хм...

А что не так? Вызов fsync(2) вызывает сбрасывание всех ассоциированных с дескриптором буферов на физический носитель. И данных, как fdatasync(), и метаданных. Файл после успешного завершения обязан обязан оказаться в детерминированном состоянии.

Даже несмотря на успешный fsync перед ним, close может завершиться неудачно, и гарантии сохранности данных нет.

Да? Приведи сценарий, когда в паре fsynс + close, fsync завершается удачно, после него вызовов write нет, но close завершается неудачно _и_ данные не сохранены (физические повреждения носителя не рассматриваем - close их тоже не обнаруживает).

Не помню, чтобы fsync был обязан сбрасывать буферы в самом жёстком диске. И он не обязан сбрасывать изменения в директории на диск. Данные файла ты «запишешь», но он может не появиться в директории при аварийном завершении работы.

Не помню, чтобы fsync был обязан сбрасывать буферы в самом жёстком диске.

И?

Данные файла ты «запишешь», но он может не появиться в директории при аварийном завершении работы.

Что такое «появление данных в директории»?

Не помню, чтобы fsync был обязан сбрасывать буферы в самом жёстком диске.

И что?

И он не обязан сбрасывать изменения в директории на диск.

Об обязан обновить метаданные и атрибуты файла на носителе.

физические повреждения носителя не рассматриваем

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

И?

И записи может не произойти.

Что такое «появление данных в директории»?

Имя файла в списке файлов. Вот создал ты файл, а его имя потом нигде не значится.

И что?

У вас же речь про запись была. Если данные до пластин диска не дошли, была ли запись?

Об обязан обновить метаданные и атрибуты файла на носителе.

Inode. Но файлу ещё и имя нужно, а оно не в inode.

Ты не ответил на вопрос.

Кстати, еще одна цитата из мана:

«A successful close does not guarantee that the data has been successfully saved to disk»

Не помню, чтобы fsync был обязан сбрасывать буферы в самом жёстком диске.

И?

И записи может не произойти.

Это недоделка, которую исправят (исправили годы назад, AFAIK).

Если данные до пластин диска не дошли, была ли запись?

Если ОС ведет себя некорректно, был ли мальчик?

Inode. Но файлу ещё и имя нужно, а оно не в inode.

Если твоя ФС записывает имена файлов асинхронно, вопрос решается элементарно: открываешь файл директории, делаешь fsync.

«A successful close does not guarantee that the data has been successfully saved to disk»

Да, поскольку может вмешаться кеширование. Я же тебе говорю: не стесняйся, можем пооворить и о ядре, а не только с точки зрения программы. Вон, уже до кешей дисков добрались в обсуждении простого труизма: «нужно проверяет коды возврата системных вызовов».

Я же тебе говорю: не стесняйся

Зачем ты мне это говоришь - тебе кажется, что я стесняюсь? Перекрестись.

можем пооворить и о ядре

Не думаю, что мне это будет интересно. В любом случае, я жду отвепта на вопрос: Вопрос по истории C'шечки (комментарий)

Какого ответа ты ждешь? Абсолютно не важно, в каком сценарии close(2) вернет ошибку, которую ты не проверил и не сообщил.

У меня нет задачи тебя переубеждать. Ты высказался, я услышал: проверять результат write(2) «бесполезно чуть менее, чем совсем», при ошибке close(2) «уже поздно что-то делать», и только для fsync(2) нужно «обрабатывать его ошибки». Так и запишем.

Какого ответа ты ждешь?

Я жду описания причин несохранения данных в указанной последовательности системных вызовов.