std::filesystem::copy_file и права - C/C++. Прикладные вопросы

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

BFE>>Или, например, std::filesystem::path не различает имя файла и имя каталога. Вернее так: имя файла и имя директории — это один и тот же объект: std::filesystem::path. Это не удобно использовать. Было бы логично иметь три типа объектов: путь, имя файла и путь_с_файлом.
·>Я тебе уже намекал — разберись как работают файловые системы, прежде чем аппелировать к логике. Дело не в std::filesystem, а в том, что с точки зрения файловых систем — файл и директория — один и тот же объект, отличие в значении атрибута "d". По сути директория это файл, содержимое которого — список файлов с дополнительной инфой (права, даты, владельцы и т.п.).

Не-не-не-не-не, не обманывайтесь. Это подход unix подобных реализаций, в которых полагают, что всякая сущность системы есть файл. Взяв за основу эту "аксиому" пытаются написать реализацию, получается, понятно, весьма криво. Эту кривизну видно даже в интерфейсе утилит. Например, глядя на команду mv a b невозможно сказать, что именно должно произойти (переименование или перенос). Нужна дополнительная информация о текущем состоянии системы.

Что же касается std::filesystem::path то для реализации вот этого хочу написать функцию:

std::pair<std::filesystem::path, std::filesystem::path> Split(const std::filesystem::path& pathName);

Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить. Из-за того, что std::filesystem::path может быть и файлом и путём, функция теряет свой тривиальный вид. Собственно, размер кода этой функции удваивается из-за выбранного подхода в std::filesystem.

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

BFE>>>Или, например, std::filesystem::path не различает имя файла и имя каталога. Вернее так: имя файла и имя директории — это один и тот же объект: std::filesystem::path. Это не удобно использовать. Было бы логично иметь три типа объектов: путь, имя файла и путь_с_файлом.
BFE>·>Я тебе уже намекал — разберись как работают файловые системы, прежде чем аппелировать к логике. Дело не в std::filesystem, а в том, что с точки зрения файловых систем — файл и директория — один и тот же объект, отличие в значении атрибута "d". По сути директория это файл, содержимое которого — список файлов с дополнительной инфой (права, даты, владельцы и т.п.).
BFE>Не-не-не-не-не, не обманывайтесь.
Тут вроде только ты обманываешься.

BFE> Это подход unix подобных реализаций, в которых полагают, что всякая сущность системы есть файл.
Допустим, что это подход unix. Хорошо, но уже лучше. Так причём тут std::filesystem?

BFE>Взяв за основу эту "аксиому" пытаются написать реализацию, получается, понятно, весьма криво. Эту кривизну видно даже в интерфейсе утилит.
Полагаю, что основа твоего непонимания в том, что только для некоего пути "/a/b/c" — невозможно сказать, является ли "c" файлом или дирой. Для этого надо залезть на диск и прочитать. Даже банальное "ls /a/b/c" — неясно. Толи выведет инфу о файле или содержимое диры.
А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.

BFE>Например, глядя на команду mv a b невозможно сказать, что именно должно произойти (переименование или перенос). Нужна дополнительная информация о текущем состоянии системы.
Потому что это интерактивная команда. Её вводят по ходу действий и обычно имеют представление о состоянии системы на момент ввода команды. Для скриптов, когда нужно выполнение точного действия — есть ключи -t и -T.

BFE>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
У path как правило есть методы "взять имя" и "взять родительский путь". По сути — части после последнего "/" и до.

BFE>Из-за того, что std::filesystem::path может быть и файлом и путём,
Нет. path может быть только путём. Посмотри в словаре значение слова "path".

BFE> функция теряет свой тривиальный вид. Собственно, размер кода этой функции удваивается из-за выбранного подхода в std::filesystem.

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

BFE>До тех пор, пока идёт работа с отдельными файлами, особых сложностей не возникает, но если начинается работа с каталогами...

А тут и <fstream> норм работает.

BFE>Ну, например, в общем случае нет возможности получить список файлов каталога. Единственный способ — это пытаться использовать std::filesystem::directory_iterator, но в процессе перечисления файлов операция инкремента может завершится с ошибкой, например потому, что следующий файл был удалён (или добавлен, это не специфицировано) другим процессом. В этом случае процесс перечисления надо начинать заново. На больших каталогах, где постоянно добавляются/удаляются файлы это процесс до конца вообще, наверно, никогда не дойдёт. Впрочем я пишу про реализацию gcc для ext4, возможно для других систем работа идёт как-то иначе (что тоже не удобно, нет идинообразия). Понятно, что в любом случае полученный список файлов может быть не актуален ещё в момент построения, но зачем останавливаться на первом же удалённом файле? Почему через него нельзя перескочить и продолжить построение списка?

Именно. Меня для написания всяких утилиток, где не нужно выжимать перфоманс, вполне устраивает <fstream>, чтобы не парясь, написать переносимую программу. Понадобилось перечислить файлы в каталоге, решил в первый раз потрогать std::filesystem, и буквально сразу же на эту жебанину напоролся.

А если нужен перфоманс, и <fstream> не устраивает по производительности, то, меня терзают смутные сомнения, и std::filesystem, скорее всего, тоже будет только тормозить и увеличивать количество геммороя, не принося никакой пользы при этом.

Я пробовал использовать под виндой на NTFS, так что этот ппц там похоже архитектурно заложен, и не зависит от ОС и файловой системы.

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

·>Я тебе уже намекал — разберись как работают файловые системы, прежде чем аппелировать к логике. Дело не в std::filesystem, а в том, что с точки зрения файловых систем — файл и директория — один и тот же объект, отличие в значении атрибута "d". По сути директория это файл, содержимое которого — список файлов с дополнительной инфой (права, даты, владельцы и т.п.).

По первому пункту возражений нет?

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

M>По первому пункту возражений нет?
По первому пункту я ничего не знаю.
Судя по беглому поиску в интернете, вроде так быть не должно...
"the iteration process itself remains valid in any case." отсюда.

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

M>>По первому пункту возражений нет?
·>По первому пункту я ничего не знаю.
·>Судя по беглому поиску в интернете, вроде так быть не должно...
·>"the iteration process itself remains valid in any case." отсюда.

Я столкнулся с этим сразу, как только попробовал. Не знаю, что там беглый поиск по интернету, но у меня не заработало под виндой c MSVC. Как оказывается, не заработало не только у меня, и не только под виндой.

Может, кривая реализация, может ещё хз что, мне от этого не легче. Желание использовать std::filesystem пропало, тем более, что свои велосипеды уже давно работают. Да и архитектура у них там странноватая, например типа деление перегружено как конкатенация пути, или как-то так. Лет 30 назад такое бы зашло, а сейчас я бы предпочел обычные кроссплатформенные обёртки над API ОС, они в общем-то везде плюс минус одинаковые, для каталогов это что-то типа find_first/find_next, можно было итераторы уже поверх этого прикручивать, как надстройку для какого-то функционального программирования, и каждый пользовался бы тем, что ему надо/удобнее. А то что сейчас есть — нафик не нужно

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

M>Я столкнулся с этим сразу, как только попробовал. Не знаю, что там беглый поиск по интернету, но у меня не заработало под виндой c MSVC. Как оказывается, не заработало не только у меня, и не только под виндой.
Хз. Но таки да, в инете попадаются жалобы, что какие-то баги, но вроде пофикшены.

M>Может, кривая реализация, может ещё хз что, мне от этого не легче. Желание использовать std::filesystem пропало, тем более, что свои велосипеды уже давно работают. Да и архитектура у них там странноватая, например типа деление перегружено как конкатенация пути, или как-то так. Лет 30 назад такое бы зашло, а сейчас я бы предпочел обычные кроссплатформенные обёртки над API ОС, они в общем-то везде плюс минус одинаковые, для каталогов это что-то типа find_first/find_next, можно было итераторы уже поверх этого прикручивать, как надстройку для какого-то функционального программирования, и каждый пользовался бы тем, что ему надо/удобнее. А то что сейчас есть — нафик не нужно
Как я понял это засунули из boost:: в std::. А оно разрабатывалось лет 20 назад... С другой стороны, если таки до ума доведено, то оно таки лучше, чем ваять свои обёртки, да так, чтобы оно хоть как-то работало везде, маки, винды, зоопарк юниксов, да ещё и всякие мобильные оси.
В Расте, пишут, дело обстоит лучше.

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

·>Тут вроде только ты обманываешься.
В чём?

BFE>> Это подход unix подобных реализаций, в которых полагают, что всякая сущность системы есть файл.
·>Допустим, что это подход unix. Хорошо, но уже лучше. Так причём тут std::filesystem?
Судя по отсылкам в документации к POSIX ( например тут) разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.

BFE>>Взяв за основу эту "аксиому" пытаются написать реализацию, получается, понятно, весьма криво. Эту кривизну видно даже в интерфейсе утилит.
·>Полагаю, что основа твоего непонимания в том, что только для некоего пути "/a/b/c" — невозможно сказать, является ли "c" файлом или дирой. Для этого надо залезть на диск и прочитать. Даже банальное "ls /a/b/c" — неясно. Толи выведет инфу о файле или содержимое диры.
Верно, что для записи "/a/b/c" — невозможно сказать, является ли "c" файлом или директорией. А вот для записи "/a/b/c/" — можно. Было бы логично определить, что все пути заканчивающиеся разделителем не являются файлами, а все не заканчивающиеся разделителями — содержат в конце имя файла. Тогда:
"a" — имя файла
"a/" — имя каталога
"/a" — имя файла
"/a/" — имя каталога
"./" — имя каталога
"." — имя файла
".." — имя файла
"../" — имя каталога
Впрочем для "." и ".." можно сделать исключение, правда, непонятно, зачем. Хотя... Не бывает систем, где "." и ".." может являться именем файла?
В общем лично у меня много вопросов к тому, почему std::filesystem выглядит так, а не иначе.

·>А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.
Во-во. "Смешались к кучу кони, люди...". Зачем это протащили в стандарт? Почему эти типы файлов не implementation defined?
Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь. Однако, если ссылка уже создана, то узнать, является ли она ссылкой на файл или директорию невозможно, если таргет был удалён. В std::filesystem::file_type просто отсутствует соответствующий тип!

BFE>>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
·>У path как правило есть методы "взять имя" и "взять родительский путь". По сути — части после последнего "/" и до.

Значит написать такую функцию просто? Напишите?

BFE>>Из-за того, что std::filesystem::path может быть и файлом и путём,
·>Нет. path может быть только путём. Посмотри в словаре значение слова "path".
Посмотрел:

A path (or filepath, file path, pathname, or similar) is a text string that uniquely specifies an item in a hierarchical file system. Generally, a path is composed of directory names, special directory specifiers and optionally a filename, separated by delimiting text.

Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...

BFE>> функция теряет свой тривиальный вид. Собственно, размер кода этой функции удваивается из-за выбранного подхода в std::filesystem.
·>

Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.

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

·>Хз. Но таки да, в инете попадаются жалобы, что какие-то баги, но вроде пофикшены.

Я на C++ 17 с MSVC2019 сижу, там вряд ли что-то пофиксят

·>Как я понял это засунули из boost:: в std::. А оно разрабатывалось лет 20 назад...

Не скажу, что бустом пользуются только маргиналы, но вот filesystem'ом из буста точно пользовали маргиналы

·>С другой стороны, если таки до ума доведено, то оно таки лучше, чем ваять свои обёртки, да так, чтобы оно хоть как-то работало везде, маки, винды, зоопарк юниксов, да ещё и всякие мобильные оси.

Особых проблем нет, в основном де версии надо поддерживать: Win32 и всё остальное. Мак — пофик. И обёртки давно в основном написаны, дописать под конкретные нужды не проблема, чем корячится с этим странным изделием

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

BFE>В общем лично у меня много вопросов к тому, почему std::filesystem выглядит так, а не иначе.
Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.

BFE>·>А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.
BFE>Во-во. "Смешались к кучу кони, люди...". Зачем это протащили в стандарт? Почему эти типы файлов не implementation defined?
Потому что и POSIX — стандарт.

BFE>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
Там же написано: Some operating systems require symlink creation to identify that the link is to a directory. Portable code should use (3,4) to create directory symlinks rather than (1,2), even though there is no distinction on POSIX systems.

BFE>Однако, если ссылка уже создана, то узнать, является ли она ссылкой на файл или директорию невозможно, если таргет был удалён.

Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.

BFE>В std::filesystem::file_type просто отсутствует соответствующий тип!
А ещё ссылка может ссылаться на сокет. Или даже на ссылку! Сколько ты предложишь добавить ещё типов?

BFE>>>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
BFE>·>У path как правило есть методы "взять имя" и "взять родительский путь". По сути — части после последнего "/" и до.
BFE>

Значит написать такую функцию просто? Напишите?
Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.

BFE>>>Из-за того, что std::filesystem::path может быть и файлом и путём,
BFE>·>Нет. path может быть только путём. Посмотри в словаре значение слова "path".
BFE>Посмотрел:
BFE>

BFE>A path (or filepath, file path, pathname, or similar) is a text string that uniquely specifies an item in a hierarchical file system. Generally, a path is composed of directory names, special directory specifiers and optionally a filename, separated by delimiting text.

BFE>

Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.

BFE>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...

к чему это.

BFE>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.

Шо?

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

BFE>>В общем лично у меня много вопросов к тому, почему std::filesystem выглядит так, а не иначе.
·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
Это не ответ на мой вопрос.
Зачем в стандарт языка тащить стандарт API системы? Может тогда в стандарт языка ещё и все остальные стандарты добавить? Стандарт USB, стандарт DVD, стандарт Bluetooth, PNG, JPEG, SVG, PDF...

BFE>>·>А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.
BFE>>Во-во. "Смешались к кучу кони, люди...". Зачем это протащили в стандарт? Почему эти типы файлов не implementation defined?
·>Потому что и POSIX — стандарт.
А ещё бывает стандарт Ada. Не понимаю я таких аргументов. POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem

BFE>>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
·>Там же написано: Some operating systems require symlink creation to identify that the link is to a directory. Portable code should use (3,4) to create directory symlinks rather than (1,2), even though there is no distinction on POSIX systems.
Именно это я и написал.

BFE>>Однако, если ссылка уже создана, то узнать, является ли она ссылкой на файл или директорию невозможно, если таргет был удалён.
·>

Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.

Значит написать такую функцию просто? Напишите?
·>Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
Зачем? Я уже писал выше по ветке здесь. То, что она должна возвращать там тоже написано.

BFE>>>>Из-за того, что std::filesystem::path может быть и файлом и путём,
BFE>>·>Нет. path может быть только путём. Посмотри в словаре значение слова "path".
BFE>>Посмотрел:
BFE>>

BFE>>A path (or filepath, file path, pathname, or similar) is a text string that uniquely specifies an item in a hierarchical file system. Generally, a path is composed of directory names, special directory specifiers and optionally a filename, separated by delimiting text.

BFE>>

·>Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
Хорошо, я переформулирую:
Из-за того, что std::filesystem::path может ссылаться (указывать, содержать последним компонентом) и файл и на каталог. Так понятно?

BFE>>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
·>

к чему это.
К универсальности языка C++.

BFE>>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.

·>Шо?
Удивительно, правда?

Из-за плохо выбранного способа записи пути пришлось в утилиту cp добавить специальные опции. Это привело к увеличению кода. О чём я и писал. Так зачем этот кривой формат втащили в стандарт языка?

BFE>Так как все эти утверждения полны внутренних противоречий, я ничего не понимаю из того, что здесь написано.
BFE>1) Вы пишите, что сложно реализовать такую функциональность. Ну так библиотека для того и нужна, чтобы реализовывать сложную функциональность. Простую функциональность можно и в прикладном коде написать.

Библиотека это никак не может реализовать, кроме как вызвав системное API. Поскольку реализация расчета эффективных прав зависит от ОС.

BFE>2) Вы пишите, что "права на ФС могут быть настроена так, что у пользователя нет прав на чтение пермиссий, но есть права на чтение контента файла". Может. И что? Это ведь не то, о чём я пишу.

Вы пишете (тут https://rsdn.org/forum/cpp.applied/8963360?tree=tree)

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

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

BFE>Функцией в одну строчку:
BFE>

BFE>bool CheckForReadPermissions(const std::filesystem::path& someFile) ( return std::ifstream(someFile).is_open(); }
BFE>

BFE>можно проверить право на чтение файла. Для записи, думаю, тоже не сложно написать. Сложнее — на исполнение, но ведь в конечном итоге у системы точно есть эта информация. Так почему её нельзя получить прямым способом, а можно только окольными путями?

Строго говоря эта функция CheckForReadPermissions проверяет не наличие/отстутствие прав, т.к. коды ошибок не учитываются.

Да, конечно у ОС есть вся информация, и есть соотв. API, но чтобы его правильно использовать нужно ознакомиться с документацией.
Идея делать какую-то общую обертку в std::filesystem на мой взгляд выглядит странной.

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

BFE>·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>Это не ответ на мой вопрос.
BFE>Зачем в стандарт языка тащить стандарт API системы?
posix — это не api конкретной системы. Да и std::filesystem умеет и win32, которая не posix.

BFE>Может тогда в стандарт языка ещё и все остальные стандарты добавить? Стандарт USB, стандарт DVD, стандарт Bluetooth, PNG, JPEG, SVG, PDF...

А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.

BFE>>>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
BFE>·>Там же написано: Some operating systems require symlink creation to identify that the link is to a directory. Portable code should use (3,4) to create directory symlinks rather than (1,2), even though there is no distinction on POSIX systems.
BFE>Именно это я и написал.

Но ты, похоже, не понял почему надо.

BFE>·>

Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.
BFE>

Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"
Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.

BFE>>>В std::filesystem::file_type просто отсутствует соответствующий тип!
BFE>·>А ещё ссылка может ссылаться на сокет. Или даже на ссылку! Сколько ты предложишь добавить ещё типов?
BFE>Я, наоборот, предлагаю экзотические типы сделать implementation-defined.
Зачем? Они не такие уж экзотические. Скажем, даже в винде есть "\\.\pipe\". Да, кстати, implementation-defined типы тоже поддерживаются.

BFE>>>

Значит написать такую функцию просто? Напишите?
BFE>·>Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
BFE>Зачем? Я уже писал выше по ветке здесь. То, что она должна возвращать там тоже написано.
Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию. Такое и AI сможет сгенерить, наверное.

BFE>>>

BFE>·>Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
BFE>Хорошо, я переформулирую:
BFE>Из-за того, что std::filesystem::path может ссылаться (указывать, содержать последним компонентом) и файл и на каталог. Так понятно?
Понятно, но не правильно. Последний компонент path — всегда имя. Каким типом файла является данное имя в данной файловой системе — по пути никак не определить. Чтобы узнать — надо прочитать содержимое фс.

BFE>>>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
BFE>·>

к чему это.
BFE>К универсальности языка C++.
Всё равно неясно. Почему в других ЯП с удачей всё в порядке, скажем, rust std::fs удача не понадобилась, а в C++ — просто место проклятое, наверное.

BFE>Удивительно, правда?

BFE>Из-за плохо выбранного способа записи пути пришлось в утилиту cp добавить специальные опции. Это привело к увеличению кода. О чём я и писал. Так зачем этот кривой формат втащили в стандарт языка?
Я же уже объяснил. Пришлось потому что cp может использоваться как интерактивная команда, которую надо по-бырому натапать, так и в скриптах. Причём тут сабж — я не понимаю.

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

BFE>>Так как все эти утверждения полны внутренних противоречий, я ничего не понимаю из того, что здесь написано.
BFE>>1) Вы пишите, что сложно реализовать такую функциональность. Ну так библиотека для того и нужна, чтобы реализовывать сложную функциональность. Простую функциональность можно и в прикладном коде написать.
M>Библиотека это никак не может реализовать, кроме как вызвав системное API. Поскольку реализация расчета эффективных прав зависит от ОС.

Для выполнения кода С++ наличие операционной системы не обязательно, хотя на практике такое встречается редко. Впрочем речь не об этом, а о том, что реализация библиотеки std::filesystem как раз и призвана изолировать код от прямых вызовов операционной системы, чтобы один и тот же код можно было использовать на разных системах.

BFE>>2) Вы пишите, что "права на ФС могут быть настроена так, что у пользователя нет прав на чтение пермиссий, но есть права на чтение контента файла". Может. И что? Это ведь не то, о чём я пишу.

M>Вы пишете (тут https://rsdn.org/forum/cpp.applied/8963360?tree=tree)
M>

M>Надо просто сравнить права, с которыми исполняется приложение, с правами файла. Что в этом сложного и зачем при этом открывать файл?

M>Так вот права на файл вы не узнаете, потому что у приложения для этого недостаточно прав. А права на чтение контента файла есть.
Ничто не мешает функции вернуть ошибку ("access denied") в таком случае.

M>Идея делать какую-то общую обертку в std::filesystem на мой взгляд выглядит странной.
Ээээ...
А зачем тогда вообще нужна std::filesystem ?

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

BFE>>·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>>Это не ответ на мой вопрос.
BFE>>Зачем в стандарт языка тащить стандарт API системы?
·>posix — это не api конкретной системы.
Да.

·> Да и std::filesystem умеет и win32, которая не posix.
А некоторые версии Windows поддерживают Posix. И что?

BFE>>Может тогда в стандарт языка ещё и все остальные стандарты добавить? Стандарт USB, стандарт DVD, стандарт Bluetooth, PNG, JPEG, SVG, PDF...
·>

В эту игру могут играть двое. А зачем в стандарт языка притащили fstream? Да тот же std::cin/std::cout — вполне себе очень даже API системы. В ту же степь atomic, chrono, mutex, random, thread. И заодно выкинем locale, map, vector, string — какое это всё имеет отношение к языку С++ ? Ведь это всё — это только часть возможного приложения языка, а C++ — универсальный язык.

PNG — ISO 15948
JPEG — ISO/IEC 10918
PDF — ISO 32000-2
Остальные тоже тоже как-то стандартизованы отдельными документами.
Что из перечисленного:
fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string
описано в отдельном стандарте?

BFE>>·>Потому что и POSIX — стандарт.
BFE>>А ещё бывает стандарт Ada.
·>Это же ЯП. Не понимаю я таких аргументов.
По какому критерию выбран именно этот стандарт для добавления в C++, а не какой-то другой?

BFE>>POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem

·>А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.
std библиотека описана в том же стандарте, что и сам язык. Более того, некоторые части std библиотеки являются неотъемлемой часть языка, например std::initializer_list.

BFE>>>>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь.
BFE>>·>Там же написано: Some operating systems require symlink creation to identify that the link is to a directory. Portable code should use (3,4) to create directory symlinks rather than (1,2), even though there is no distinction on POSIX systems.
BFE>>Именно это я и написал.

·>Но ты, похоже, не понял почему надо.
Нет, это вы не понимаете, что получилось в результате.

BFE>>·>

Что в лоб, что по лбу. Потому что ссылка содержит в себе путь, а не файл или директорию.
BFE>>

Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"
·>Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
Скажите, какая цель создания библиотеки std::filesystem ?

·>Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.
Да неужели?
А вот скажите, для работы с (ex)FAT накопителями, которые, по числу, видимо, превосходят количество накопителей на других форматах файловых систем, библиотека std::filesystem приспособлена хорошо?

BFE>>Я, наоборот, предлагаю экзотические типы сделать implementation-defined.
·>Зачем? Они не такие уж экзотические. Скажем, даже в винде есть "\\.\pipe\".
Уверен, что если провести опрос, то окажется что более 90% программистов никогда в жизни не работали с такими файлами именно как с файлами.

·>Да, кстати, implementation-defined типы тоже поддерживаются.

я знаю.

·>Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию.
pathName first second
"" "" ""
"/" "/" ""
"a" "" "a"
"/a" "/" "a"
"b/a" "b/" "a"
"a/" "" "a"
"a/." "" "a"
"a/.." "a/.." ""
"/a/b" "/a" "b"
"../b" ".." "b"
"./b" "." "b"

·>Такое и AI сможет сгенерить, наверное.
AI сгенерил код, что зацикливается на некоторых путях.

·>Понятно, но не правильно. Последний компонент path — всегда имя. Каким типом файла является данное имя в данной файловой системе — по пути никак не определить. Чтобы узнать — надо прочитать содержимое фс.
Укажите на имя для пути "/a/" и для пути "/"

·>Всё равно неясно. Почему в других ЯП с удачей всё в порядке, скажем, rust std::fs удача не понадобилась, а в C++ — просто место проклятое, наверное.
Другие языки тоже универсальные?
rust уже стандартизовали?

·>Я же уже объяснил. Пришлось потому что cp может использоваться как интерактивная команда, которую надо по-бырому натапать, так и в скриптах. Причём тут сабж — я не понимаю.
я подожду кода для задачи выше.

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

BFE>>>·>Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>>>Это не ответ на мой вопрос.
BFE>>>Зачем в стандарт языка тащить стандарт API системы?
BFE>·>posix — это не api конкретной системы.
BFE>Да.

Т.е. твоя идея std::posix_filesystem — не состоятельна и "Зачем в стандарт языка тащить стандарт API системы" — дурацкий вопрос.

BFE>А некоторые версии Windows поддерживают Posix. И что?
Я в курсе. И ничего.

BFE>Остальные тоже тоже как-то стандартизованы отдельными документами.
И что?

BFE>Что из перечисленного:
BFE>fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string
BFE>описано в отдельном стандарте?
Не знаю. А какая разница? Разбираться лень, но например thread по сути поделие для замены posix-тредов.
Кстати, а в каком отдельном стандарте описано std::filesystem?

BFE>·>Это же ЯП. Не понимаю я таких аргументов.
BFE>По какому критерию выбран именно этот стандарт для добавления в C++, а не какой-то другой?
Понятия не имею. А какая разница?

BFE>>>POSIX — это только часть возможного приложения языка, а C++ — универсальный язык. Хотите добавить что-то специфичное, то так и назовите std::posix_filesystem

BFE>·>А я понимаю: ты путаешь ЯП и стандартную библиотеку. Так вот... std — это стандартная библиотека языка, а не язык.
BFE>std библиотека описана в том же стандарте, что и сам язык. Более того, некоторые части std библиотеки являются неотъемлемой часть языка, например std::initializer_list.
И что? И кто из fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string является неотъемлемой часть языка?

BFE>>>

Ладно, если вы не понимаете словами, попробую описать задачу. У вас есть символьная ссылка, то на что она указывает не существует. Вопрос: как создать тот путь, на который она указывает, чтобы не нарушить требование выше: "Portable code should use (3,4)"
BFE>·>Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
BFE>Скажите, какая цель создания библиотеки std::filesystem ?
Такая же как у fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string.

BFE>·>Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.
BFE>Да неужели?
Ну да.

BFE>А вот скажите, для работы с (ex)FAT накопителями, которые, по числу, видимо, превосходят количество накопителей на других форматах файловых систем, библиотека std::filesystem приспособлена хорошо?
define "хорошо". И что, по-твоему, приспособлено лучше?

BFE>·>Зачем? Они не такие уж экзотические. Скажем, даже в винде есть "\\.\pipe\".
BFE>Уверен, что если провести опрос, то окажется что более 90% программистов никогда в жизни не работали с такими файлами именно как с файлами.
И что?

BFE>·>Да, кстати, implementation-defined типы тоже поддерживаются.

BFE>я знаю.
А в чём тогда претензия?

BFE>·>Не очень ясно написано. Напиши тесты, поглядим как сделать имплементацию.
BFE>pathName first second
BFE>"" "" ""
BFE>"/" "/" ""
BFE>"a" "" "a"
BFE>"/a" "/" "a"
BFE>"b/a" "b/" "a"
BFE>"a/" "" "a"
BFE>"a/." "" "a"
BFE>"a/.." "a/.." ""
BFE>"/a/b" "/a" "b"
BFE>"../b" ".." "b"
BFE>"./b" "." "b"
Это просто parent_path и filename. Вот только почему-то ты хочешь случайно расставленные / с неясно какой целью. Добавляй их сам. Я логику не улавливаю.
Покажи решение на ЯП/либе, в которых, есть по-твоему правльно реализованный path.

BFE>·>Понятно, но не правильно. Последний компонент path — всегда имя. Каким типом файла является данное имя в данной файловой системе — по пути никак не определить. Чтобы узнать — надо прочитать содержимое фс.
BFE>Укажите на имя для пути "/a/" и для пути "/"
В данных путях его нет, has_filename возвращает false.

BFE>·>Всё равно неясно. Почему в других ЯП с удачей всё в порядке, скажем, rust std::fs удача не понадобилась, а в C++ — просто место проклятое, наверное.
BFE>Другие языки тоже универсальные?
А какие ты не универсальные языки знаешь? Ну кроме sql, html?

BFE>rust уже стандартизовали?
Не знаю. А какая разница?

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

M>>

M>>Надо просто сравнить права, с которыми исполняется приложение, с правами файла. Что в этом сложного и зачем при этом открывать файл?

M>>Так вот права на файл вы не узнаете, потому что у приложения для этого недостаточно прав. А права на чтение контента файла есть.
BFE>Ничто не мешает функции вернуть ошибку ("access denied") в таком случае.

Ну допустим вернулась эта ошибка "access denied". И что дальше-то будешь делать?

BFE>Для выполнения кода С++ наличие операционной системы не обязательно, хотя на практике такое встречается редко. Впрочем речь не об этом, а о том, что реализация библиотеки std::filesystem как раз и призвана изолировать код от прямых вызовов операционной системы, чтобы один и тот же код можно было использовать на разных системах.

Есть функционал, который относительно легко изолируется от API OS, например примитивы синхронизациия, работа с HTTP, text encoding.
А вот эффективные права, это штука целиком и полностью завязанная на OS и ФС.
Как я понимаю, std::filesystem оперирует с POSIX правами. Трансляция между POSIX ACL и NTFS ACL неоднозначная.

BFE>Ничто не мешает функции вернуть ошибку ("access denied") в таком случае.

А значит у Вас в коде будет две ветки алгоритма предпроверки перед копированием:
1) через эфф. права
2) через ifstream.is_open на случай, если (1) вернул ошибку

Смысл всех этих ухищрений для меня остается неясным.

BFE>А зачем тогда вообще нужна std::filesystem ?

Хм, наверное как posix-совместимая обертка для упрощения написания кросплатформенного кода в _простых_ случаях.

	От:	·
	Дата:	16.07.25 12:55
	Оценка:	+1

	От:	B0FEE664
	Дата:	16.07.25 16:12
	Оценка:

	От:	·
	Дата:	16.07.25 19:01
	Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	16.07.25 19:22
Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	16.07.25 19:24
Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	14.08.25 10:14
Оценка:

	От:	m2user
	Дата:	18.07.25 21:28
	Оценка:

	От:	m2user
	Дата:	23.07.25 19:59
	Оценка: