История изменений

вместо того, чтобы сразу сказать «да пох, демон некритичный, вероятность ошибки мала, я тупо забил; отсосите»

Я это раз 10 уже написал.

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

Я не знал как её обработать, оценил вероятность и риски как ничтожные, и забил, только и всего. Я же не утверждал что это праильно или что так и надо делать. Просто рассказал как есть и откуда эта лажа. Мимокрокодилы утверждающие что уж они-то в отличии от поганого сишника знают как правильно писать программы, решили поучить поганого сишника. Ну а чего бы и не послушать что предложат, вдруг годноту какую. А хрен там - предлагают как сделать ещё хуже чем есть.

Еще и «безопасность» какая-то постоянно лезет.

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

создавала одноименный каталог.

Да, бывает. Создают всякое временное, для каких-то своих нужд. Но прикол в том, что эта софтинка слушает inotify на предмет mv файла в спул, а не создания. (mv/rename атомарная для юзерспейса операция, не надо заморачиваться с локами и пр.) Т.е. при создании директории в спуле данная функция с лажей вызвана просто не будет. И при сканировании спула при переподключении тоже не будет вызвана, потому что при сканировании вызывается только на regular файлы, которые могли появиться там пока связи не было или программа не работала. Так что даже случайное создание директории никак не приведёт к возникновению неприятной ситуации. Т.е. это надо специально и сознательно сделать mv some_directory /var/spool/xmppcd/out. Программ, которые случайно могут сделать именно mv директории в spool я не знаю ни одной. С таким же успехом можно всерьёз рассматривать вероятность замыкания отвёрткой дорожек на плате.

ЗЫ: Цель всей этой многодневное писанины, на самом деле изучение специфической группы любителей безопасных язычков, а вовсе не какой-то там спор ради чего-то там. Вот сколько сюда забрело их все до единого почему-то обладают каким-то туннельным зрением - «о, в этих строчках ошибка, надо return/abort». Для чего нужен этот код их вообще не интересует. И все совершенно одинаковые с одинаковым ходом мысли, как с конвейера какого-то. Ну интересно же - откуда вот этот весь трындец с современным типа прикладным софтом взялся и чем закончится.

вместо того, чтобы сразу сказать «да пох, демон некритичный, вероятность ошибки мала, я тупо забил; отсосите»

Я это раз 10 уже написал.

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

Я не знал как её обработать, оценил вероятность и риски как ничтожные, и забил, только и всего. Я же не утверждал что это праильно или что так и надо делать. Просто рассказал как есть и откуда эта лажа. Мимокрокодилы утверждающие что уж они-то в отличии от поганого сишника знают как правильно писать программы, решили поучить поганого сишника. Ну а чего бы и не послушать что предложат, вдруг годноту какую. А хрен там - предлагают как сделать ещё хуже чем есть.

Еще и «безопасность» какая-то постоянно лезет.

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

создавала одноименный каталог.

Да, бывает. Создают всякое временное, для каких-то своих нужд. Но прикол в том, что эта софтинка слушает inotify на предмет mv файла в спул, а не создания. (mv/rename атомарная для юзерспейса операция, не надо заморачиваться с локами и пр.) Т.е. при создании директории в спуле данная функция с лажей вызвана просто не будет. И при сканировании спула при переподключении тоже не будет вызвана, потому что при сканировании вызывается только на regular файлы, которые могли появиться там пока связи не было или программа не работала. Так что даже случайное создание директории никак не приведёт к возникновению неприятной ситуации. Т.е. это надо специально и сознательно сделать mv some_directory /var/lib/xmppcd/spool/out. Программ, которые случайно могут сделать именно mv директории в spool я не знаю ни одной. С таким же успехом можно всерьёз рассматривать вероятность замыкания отвёрткой дорожек на плате.

ЗЫ: Цель всей этой многодневное писанины, на самом деле изучение специфической группы любителей безопасных язычков, а вовсе не какой-то там спор ради чего-то там. Вот сколько сюда забрело их все до единого почему-то обладают каким-то туннельным зрением - «о, в этих строчках ошибка, надо return/abort». Для чего нужен этот код их вообще не интересует. И все совершенно одинаковые с одинаковым ходом мысли, как с конвейера какого-то. Ну интересно же - откуда вот этот весь трындец с современным типа прикладным софтом взялся и чем закончится.

вместо того, чтобы сразу сказать «да пох, демон некритичный, вероятность ошибки мала, я тупо забил; отсосите»

Я это раз 10 уже написал.

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

Я не знал как её обработать, оценил вероятность и риски как ничтожные, и забил, только и всего. Я же не утверждал что это праильно или что так и надо делать. Просто рассказал как есть и откуда эта лажа. Мимокрокодилы утверждающие что уж они-то в отличии от поганого сишника знают как правильно писать программы, решили поучить поганого сишника. Ну а чего бы и не послушать что предложат, вдруг годноту какую. А хрен там - предлагают как сделать ещё хуже чем есть.

Еще и «безопасность» какая-то постоянно лезет.

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

создавала одноименный каталог.

Да, бывает. Создают всякое временное, для каких-то своих нужд. Но прикол в том, что эта софтинка слушает inotify на предмет mv файла в спул, а не создания. (mv/rename атомарная для юзерспейса операция, не надо заморачиваться с локами и пр.) Т.е. при создании директории в спуле данная функция с лажей вызвана просто не будет. И при сканировании спула при переподключении тоже не будет вызвана, потому что при сканировании вызывается только на regular файлы, которые могли появиться там пока связи не было или программа не работала. Так что даже случайное создание директории никак не приведёт к возникновению неприятной ситуации. Т.е. это надо специально и сознательно сделать mv some_directory /var/lib/xmppcd/spool/out. Программ, которые случайно могут сделать именно mv директории в spool я не знаю ни одной. С таким же успехом можно всерьёз рассматривать вероятность замыкания отвёрткой дорожек на плате.

ЗЫ: Цель всей этой многодневное писанины, на самом деле изучение специфической группы любителей безопасных язычков, а вовсе не какой-то там спор ради чего-то там. Вот сколько сюда забрело их все до единого почему-то обладают каким-то туннельным зрением - «о, в этих строчках ошибка, надо return/abort». Для чего нужен этот код их вообще не интересует. И все совершенно одинаковые с одинаковым ходом мысли, как с конвейера какого-то. Ну интересно же - откуда вот этот весь трындец с софтом взялся и чем закончится.

вместо того, чтобы сразу сказать «да пох, демон некритичный, вероятность ошибки мала, я тупо забил; отсосите»

Я это раз 10 уже написал.

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

Я не знал как её обработать, оценил вероятность и риски как ничтожные, и забил, только и всего. Я же не утверждал что это праильно или что так и надо делать. Просто рассказал как есть и откуда эта лажа. Мимокрокодилы утверждающие что уж они-то в отличии от поганого сишника знают как правильно писать программы, решили поучить поганого сишника. Ну а чего бы и не послушать что предложат, вдруг годноту какую. А хрен там - предлагают как сделать ещё хуже чем есть.

Еще и «безопасность» какая-то постоянно лезет.

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

создавала одноименный каталог.

Да, бывает. Создают всякое временное, для каких-то своих нужд. Но прикол в том, что эта софтинка слушает inotify на предмет mv файла в спул, а не создания. (mv/rename атомарная для юзерспейса операция, не надо заморачиваться с локами и пр.) Т.е. при создании директории в спуле данная функция с лажей вызвана просто не будет. И при сканировании спула при переподключении тоже не будет вызвана, потому что при сканировании вызывается только на regular файлы, которые могли появиться там пока связи не было или программа не работала. Так что даже случайное создание директории никак не приведёт к возникновению неприятной ситуации. Т.е. это надо специально и сознательно сделать mv some_directory /var/lib/xmppcd/spool/out. Программ, которые случайно могут сделать именно mv директории в spool я не знаю ни одной. С таким же успехом можно всерьёз рассматривать вероятность замыкания отвёрткой дорожек на плате.