Re[5]: А как плюсовыми средствами создать файл только если о - C/C++. Прикладные вопросы

Здравствуйте, удусекшл, Вы писали:

У>Заголовок темы перечитай, что ли.

а ты не огрызайся, а почекай лучше что тебе предлагают ..

(всё в точности с твоими требованиями в заголовке темы)

CreateFileA function (fileapi.h)
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea

HANDLE CreateFileA(
  [in]           LPCSTR                lpFileName,
  [in]           DWORD                 dwDesiredAccess,
  [in]           DWORD                 dwShareMode,
  [in, optional] LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  [in]           DWORD                 dwCreationDisposition,
  [in]           DWORD                 dwFlagsAndAttributes,
  [in, optional] HANDLE                hTemplateFile
);

[in] dwCreationDisposition

CREATE_NEW — Creates a new file, only if it does not already exist.

собственно и вопрос с правами тут судя по всему решается автоматически

т.к. ничего специально на чтение открывать — не надо ..

Всем привет!

Собственно, мои приключения с std::fopen из-за того и были, что вроде как стандартными средствами такое никак не сделать. Нагуглил этот костыль на стек оверфлоу, там ничего лучше не предложили. Неужели это такой редкий случай, что его за всё время существования std::iostreams так в стандарт и не завезли?

Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается

Здравствуйте, Kernan, Вы писали:

У>>Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается
K>std::filesystem::exists?

Там тогда надо ещё потанцевать и проверить, не является ли это каталогом. Это раз.
Во-вторых: окей, я проверил, файла не существует, можно создавать, но пока я в носу ковырял, кто-то другой его создал, и я молча перезапишу чужой файл

Здравствуйте, удусекшл, Вы писали:

У>А как плюсовыми средствами создать файл только если он не существует?

собственно это всё даже в гугле есть

если пустой файл считается как не существующий, то открой файл для добавления и проверь указатель на файл и его позицию в файле ..

если ноль, значит файл новый или пустой

	Скрытый текст
	`FILE* pFile = fopen(theFilePath, "a+"); if (pFile && gfetpos(pFile) == 0) { // Either file didn't previously exist or it did and was empty } else if (pFile) { fclose(pFile); }` Как создать файл, только если его не существует? https://question-it.com/questions/4828340/kak-sozdat-fajl-tolko-esli-ego-ne-suschestvuet

ну либо проверяй файл на существование ..

а потом если его нет создавай файл для записи (ну или для добавления "a+", без разницы)

Скрытый текст

Какой лучший способ проверить, существует ли файл в C?
https://qastack.ru/programming/230062/whats-the-best-way-to-check-if-a-file-exists-in-c

int exists(const char *fname)
{
    FILE *file;
    if ((file = fopen(fname, "r")))
    {
        fclose(file);
        return 1;
    }
    return 0;
}

Проверка на существование файла средствами с++
https://ru.stackoverflow.com/questions/946006/%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%D0%BD%D0%B0-%D1%81%D1%83%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%84%D0%B0%D0%B9%D0%BB%D0%B0-%D1%81%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B0%D0%BC%D0%B8-%D1%81

ifstream iff("filename.dat");
if(iff.bad()==true) cout<<"file is not present"; else cout<<"file is present";

Здравствуйте, xma, Вы писали:

У>>В продакшн я бы такое не стал бы отдавать

xma>а что не так ?

Неатомарность

xma>это классика же через fopen(filename, "r") проверять существование файла ..

А если пользователю прав на чтение не хватает? Файл есть, записать можно, а прочитать — нельзя?
Хреновая какая-то классика

Здравствуйте, σ, Вы писали:

σ>>>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

σ>Я предполагаю что шизы из Microsoft решили, что зарезервированы (не могут объявляться/определяться программой) идентификаторы как описано в том разделе.
σ>open не зарезервирован и может определяться программой. Если будет конфликт с open, который пришёл извне программы, например, из fcntl.h, то тут виноват fcntl.h.

Идея понятна, но тогда почему open должен был подпадать под это требование, а CreateFile — нет? Кто мешает определить такое имя в юзерском коде?
Даже если предположить, что они пользовались такой логикой, то что-то не сходится.

У меня тут другое предположение: периодически у них формулировалась необходимость реализовать и дать программам POSIX-подсистему. В Posix явно определён свой open(). Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная. В таком случае им нужно различать тот open(), который полноценный POSIX, и тот open(), который эмуляция в CRT в пределах того, что они хотят в него вложить. Логично тогда второй назвать _open() (минимум замены), или crt_open, или ещё как-то.
И вот тогда это требование не создавать конфликта обретает плоть...

Здравствуйте, удусекшл, Вы писали:

У>Собственно, мои приключения с std::fopen из-за того и были, что вроде как стандартными средствами такое никак не сделать.

Ну... в MSVC, и, подозреваю, не только, потоки сделаны поверх FILE*, так что приключения бы только удлиннились.

У>Неужели это такой редкий случай, что его за всё время существования std::iostreams так в стандарт и не завезли?

iostreams говно, и далеко не только поэтому.

Использовать платформенные API или более вменяемые сторонние кросплатформенные обёртки (вроде QFile).

Здравствуйте, vsb, Вы писали:

vsb>Вроде у микрософта вообще нет обычного open, только _open, или я туплю?

Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

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

Хотя, может я отстал от жизни, и "_open" в линупсы тоже подвезли

Здравствуйте, удусекшл, Вы писали:

У>Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается
std::filesystem::exists?

Здравствуйте, xma, Вы писали:

У>>А если пользователю прав на чтение не хватает?

xma>про это в старт посте — речи не было ..

И что? Твой код делает не то, что нужно, этого достаточно

Здравствуйте, xma, Вы писали:

У>>Во-вторых: окей, я проверил, файла не существует, можно создавать, но пока я в носу ковырял, кто-то другой его создал, и я молча перезапишу чужой файл

xma>открывай тогда эксклюзивно файл — через виндовый CreateFile(..)

Заголовок темы перечитай, что ли.

Здравствуйте, xma, Вы писали:

У>>И что? Твой код делает не то, что нужно, этого достаточно

xma>он делает то что ты и просил — в заголовке темы ..

а что тебе реально было надо — тут телепатов нету ..

Он делает не то, что я просил.

Здравствуйте, xma, Вы писали:

У>>Заголовок темы перечитай, что ли.

xma>а ты не огрызайся, а почекай лучше что тебе предлагают ..

(всё в точности с твоими требованиями в заголовке темы)

xma>CreateFileA function (fileapi.h)

Спасибо, я винапи знаю. Перечитай таки заголовок

Здравствуйте, Alexander G, Вы писали:

AG>Ну... в MSVC, и, подозреваю, не только, потоки сделаны поверх FILE*, так что приключения бы только удлиннились.

Думаешь? А почему не через POSIX APIшную open? Или вообще не через WinAPI?
Я думаю, что как не поверх FILE*, а у плюсовых потоков свои отдельные буфера, иначе зачем нужно было бы sync_with_stdio?

AG>iostreams говно, и далеко не только поэтому.
AG>Использовать платформенные API или более вменяемые сторонние кросплатформенные обёртки (вроде QFile).

Да мне пофигу, что гавно. Я писал мелкую утилитку, и мне нах не впёрлось втаскивать туда что-то кроме стандартной библиотеки.

Здравствуйте, xma, Вы писали:

У>>А как плюсовыми средствами создать файл только если он не существует?

xma>собственно это всё даже в гугле есть

xma>если пустой файл считается как не существующий, то открой файл для добавления и проверь указатель на файл и его позицию в файле ..

если ноль, значит файл новый или пустой

Допустим, мне нельзя перетирать даже пустой файл, что тогда?
Ну и так-то, это тоже костыль

xma>ну либо проверяй файл на существование ..

а потом если его нет создавай файл для записи (ну или для добавления "a+", без разницы)

В продакшн я бы такое не стал бы отдавать

Здравствуйте, удусекшл, Вы писали:

У>Здравствуйте, Alexander G, Вы писали:

AG>>Ну... в MSVC, и, подозреваю, не только, потоки сделаны поверх FILE*, так что приключения бы только удлиннились.

У>Думаешь?

Знаю.

https://github.com/microsoft/STL/blob/main/stl/inc/fstream#L63
https://github.com/microsoft/STL/blob/main/stl/src/fiopen.cpp#L71

У>А почему не через POSIX APIшную open? Или вообще не через WinAPI?

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

У>Да мне пофигу, что гавно. Я писал мелкую утилитку, и мне нах не впёрлось втаскивать туда что-то кроме стандартной библиотеки.

Ну окей, std::fopen — это стандартная библиотека.

Получить файловый дескриптор платформо-зависимыми средствами (open/_sopen_s) и преобразовать его в FILE* через fdopen

Здравствуйте, vsb, Вы писали:

vsb>Получить файловый дескриптор платформо-зависимыми средствами (open/_sopen_s) и преобразовать его в FILE* через fdopen

Ну вот это уже не C++.

И микрософт, как всегда, пошел своим путём, и там либо городить ifdef'ы, либо глотать варнинги и риски, что в будущем эту функцию вообще уберут

Здравствуйте, удусекшл, Вы писали:

vsb>>Получить файловый дескриптор платформо-зависимыми средствами (open/_sopen_s) и преобразовать его в FILE* через fdopen

У>Ну вот это уже не C++.

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

У>И микрософт, как всегда, пошел своим путём, и там либо городить ifdef'ы, либо глотать варнинги и риски, что в будущем эту функцию вообще уберут

Ну или так, да. Вряд ли её уберут.

Здравствуйте, удусекшл, Вы писали:

У>Допустим, мне нельзя перетирать даже пустой файл, что тогда?

ну тогда второй вариант ..

У>Ну и так-то, это тоже костыль

C/C++ ваще из костылей состоит ..

У>В продакшн я бы такое не стал бы отдавать

а что не так ?

это классика же через fopen(filename, "r") проверять существование файла ..

Здравствуйте, удусекшл, Вы писали:

У>А если пользователю прав на чтение не хватает?

про это в старт посте — речи не было ..

Здравствуйте, удусекшл, Вы писали:

У>Обычный open есть, но объявлен депрекейтед и генерит варнинги.

Я думаю, что он не исчезнет, т.к. обеспечивает какую-никакую совместимость с юниксовым кодом.

У>и редиски в данном случае линупсоиды, но легче от этого не становится.

Подозреваю, что эти функции писали ещё до того, как придумали стандарт С и этот пункт.

У>Хотя, может я отстал от жизни, и "_open" в линупсы тоже подвезли

Вроде нет.

Здравствуйте, удусекшл, Вы писали:

У>Во-вторых: окей, я проверил, файла не существует, можно создавать, но пока я в носу ковырял, кто-то другой его создал, и я молча перезапишу чужой файл

открывай тогда эксклюзивно файл — через виндовый CreateFile(..)

Блокирование файла
https://www.cyberforum.ru/post3283129.html

Здравствуйте, удусекшл, Вы писали:

У>И что? Твой код делает не то, что нужно, этого достаточно

он делает то что ты и просил — в заголовке темы ..

а что тебе реально было надо — тут телепатов нету ..

У>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

А почему CreateFileW не нарушает Standard C rules? Он не начинается с прочерка.

Здравствуйте, удусекшл, Вы писали:

У>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

Не могу найти такого требования в стандарте C.

У>и редиски в данном случае линупсоиды, но легче от этого не становится.
У>Хотя, может я отстал от жизни, и "_open" в линупсы тоже подвезли

И не начинали.

У>>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

N>Не могу найти такого требования в стандарте C.

http://port70.net/~nsz/c/c11/n1570.html#7.1.3

Здравствуйте, σ, Вы писали:

У>>>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>>>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

N>>Не могу найти такого требования в стандарте C.

σ>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

Не будет ли так любезен дорогой коллега объяснить конкретнее, какой подпункт данного пункта в какой конкретно формулировке подразумевает такое требование?

У>>>>Обычный open есть, но объявлен депрекейтед и генерит варнинги. А "_open" — не уверен, что он есть во всяких линупсах. И константы опций в линупсах тоже без '_', а у МС с ним. И тут вроде бы МС все правильно делает:
У>>>>

The name is deprecated because it doesn't follow the Standard C rules for implementation-specific names. However, the function is still supported.

N>>>Не могу найти такого требования в стандарте C.

σ>>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

N>Не будет ли так любезен дорогой коллега объяснить конкретнее, какой подпункт данного пункта в какой конкретно формулировке подразумевает такое требование?

Я предполагаю что шизы из Microsoft решили, что зарезервированы (не могут объявляться/определяться программой) идентификаторы как описано в том разделе.
open не зарезервирован и может определяться программой. Если будет конфликт с open, который пришёл извне программы, например, из fcntl.h, то тут виноват fcntl.h.

Здравствуйте, удусекшл, Вы писали:

У>Здравствуйте, Kernan, Вы писали:

У>>>Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается
K>>std::filesystem::exists?

У>Там тогда надо ещё потанцевать и проверить, не является ли это каталогом. Это раз.

_stat. В Linux и прочих UNIX-подобных системах — stat. Если файл уже открыт, можно функцию _fstat использовать, у которой параметр — файловый дескриптор, а не путь.

Здравствуйте, AleksandrN, Вы писали:

У>>Там тогда надо ещё потанцевать и проверить, не является ли это каталогом. Это раз.

AN>_stat. В Linux и прочих UNIX-подобных системах — stat. Если файл уже открыт, можно функцию _fstat использовать, у которой параметр — файловый дескриптор, а не путь.

Ну, так я и говорю — танцевать надо. А _fstat, кстати, получает целочисленный дескриптор, и не не уверен, что из FILE* его можно вытащить

Здравствуйте, netch80, Вы писали:

N>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.

А вот про это можно поподробнее? Я лично не вижу особых проблем

Здравствуйте, netch80, Вы писали:

N>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
Разве? А как же Windows Subsystem for Linux?

Здравствуйте, удусекшл, Вы писали:

У>Ну, так я и говорю — танцевать надо. А _fstat, кстати, получает целочисленный дескриптор, и не не уверен, что из FILE* его можно вытащить

int fileno(FILE *stream)

Здравствуйте, B0FEE664, Вы писали:

N>>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
BFE>Разве? А как же Windows Subsystem for Linux?

А так же Microsoft POSIX subsystem, Windows Services for UNIX. Я не уверен на 100%, но по-моему какая-то венда с этими нашлёпками даже была POSIX-сертифицирована.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, B0FEE664, Вы писали:

N>>>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
BFE>>Разве? А как же Windows Subsystem for Linux?

Все драйвера свои.

vsb>А так же Microsoft POSIX subsystem, Windows Services for UNIX. Я не уверен на 100%, но по-моему какая-то венда с этими нашлёпками даже была POSIX-сертифицирована.

Оно поверх ядерного API (причём особым образом), а не поверх WinAPI.

σ>>>>http://port70.net/~nsz/c/c11/n1570.html#7.1.3

σ>>Я предполагаю что шизы из Microsoft решили, что зарезервированы (не могут объявляться/определяться программой) идентификаторы как описано в том разделе.
σ>>open не зарезервирован и может определяться программой. Если будет конфликт с open, который пришёл извне программы, например, из fcntl.h, то тут виноват fcntl.h.

N>Идея понятна, но тогда почему open должен был подпадать под это требование, а CreateFile — нет? Кто мешает определить такое имя в юзерском коде?

CreateFile __stdcall, а юзерский код по-умолчанию __cdecl. Хотя да, это не спасёт от конфликтов в сырцах, только при линковке.

N>Даже если предположить, что они пользовались такой логикой, то что-то не сходится.

N>У меня тут другое предположение: периодически у них формулировалась необходимость реализовать и дать программам POSIX-подсистему. В Posix явно определён свой open(). Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная. В таком случае им нужно различать тот open(), который полноценный POSIX, и тот open(), который эмуляция в CRT в пределах того, что они хотят в него вложить. Логично тогда второй назвать _open() (минимум замены), или crt_open, или ещё как-то.
N>И вот тогда это требование не создавать конфликта обретает плоть...

Если сам всё знаешь, зачем меня просишь объяснить тогда?

Здравствуйте, σ, Вы писали:

σ>Если сам всё знаешь, зачем меня просишь объяснить тогда?

Кто сказал, что знаю? Предполагаю. Уверен процентов на 70-80. Но для твёрдого утверждения этого мало.

Здравствуйте, удусекшл, Вы писали:

У>Всем привет!

У>Собственно, мои приключения с std::fopen из-за того и были, что вроде как стандартными средствами такое никак не сделать. Нагуглил этот костыль на стек оверфлоу, там ничего лучше не предложили. Неужели это такой редкий случай, что его за всё время существования std::iostreams так в стандарт и не завезли?

У>Это при том, что в POSIX есть open с O_CREAT|O_EXCL, через которую в итоге всё равно всё делается

Создать файл с гарантированно уникальным именем (uuid какой-нибудь), затем std::filesystem::rename, а при неудаче удалить?

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, netch80, Вы писали:

N>>Сделать POSIX поверх WinAPI они не могли, глубинная семантика очень разная.
BFE>Разве? А как же Windows Subsystem for Linux?

Ну WSL как раз пример того что не смогли.
Первая версия WSL была вида подсистемы в Windows и не взлетела.
А вот вторая версия WSL это на самом деле Ubuntu в виртуалке,
что это как не "они не могли, глубинная семантика очень разная"?

	От:	xma
	Дата:	04.02.22 15:55
	Оценка:	1 (1) +1 -1

	От:	удусекшл
	Дата:	04.02.22 13:21
	Оценка:	18 (1) +1

	От:	удусекшл
	Дата:	04.02.22 14:18
	Оценка:	1 (1) +1

	От:	xma
	Дата:	04.02.22 13:54
	Оценка:	+2

	От:	удусекшл
	Дата:	04.02.22 14:16
	Оценка:	+1 -1

От:	netch80	http://netch80.dreamwidth.org/
Дата:	05.02.22 15:57
Оценка:	8 (1)

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	04.02.22 14:17
Оценка:	+1

	От:	ути-пути
	Дата:	26.04.22 06:36
	Оценка:

	От:	B0FEE664
	Дата:	07.02.22 14:15
	Оценка:

	От:	vsb
	Дата:	07.02.22 14:21
	Оценка: