Сообщение Re[9]: std::filesystem::copy_file и права от 18.07.2025 9:32
Изменено 18.07.2025 12:01 ·
Re[9]: std::filesystem::copy_file и права
Здравствуйте, B0FEE664, Вы писали:
BFE>В общем лично у меня много вопросов к тому, почему std::filesystem выглядит так, а не иначе.
Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>·>А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.
BFE>Во-во. "Смешались к кучу кони, люди...". Зачем это протащили в стандарт? Почему эти типы файлов не implementation defined?
Потому что и POSIX — стандарт.
BFE>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь. Однако, если ссылка уже создана, то узнать, является ли она ссылкой на файл или директорию невозможно, если таргет был удалён. В std::filesystem::file_type просто отсутствует соответствующий тип!
Там же написано: 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>>>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
BFE>·>У path как правило есть методы "взять имя" и "взять родительский путь". По сути — части после последнего "/" и до.
BFE>
Значит написать такую функцию просто? Напишите?
Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
BFE>>>Из-за того, что std::filesystem::path может быть и файлом и путём,
BFE>·>Нет. path может быть только путём. Посмотри в словаре значение слова "path".
BFE>Посмотрел:
BFE>
Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
BFE>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
к чему это.
BFE>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.
Шо?
BFE>В общем лично у меня много вопросов к тому, почему std::filesystem выглядит так, а не иначе.
Ты же сам ответил на свой вопрос: разработка std::filesystem базировалась на этом взятом из UNIX систем стандарте. Очевидно же.
BFE>·>А ещё бывают другие типы файлов — ссылки, сокеты, пайпы, етс.
BFE>Во-во. "Смешались к кучу кони, люди...". Зачем это протащили в стандарт? Почему эти типы файлов не implementation defined?
Потому что и POSIX — стандарт.
BFE>Или, вот ссылки, к примеру. В документации сказано, что ссылку на директорию и ссылку на файл надо создавать разными функциями здесь. Однако, если ссылка уже создана, то узнать, является ли она ссылкой на файл или директорию невозможно, если таргет был удалён. В std::filesystem::file_type просто отсутствует соответствующий тип!
Там же написано: 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>>>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
BFE>·>У path как правило есть методы "взять имя" и "взять родительский путь". По сути — части после последнего "/" и до.
BFE>
Непонятно что именно такая функция должна делать в разных сценариях и зачем. Для извлечения разных компонент пути есть функции parent_path, relative_path, filename и т.п.
BFE>>>Из-за того, что std::filesystem::path может быть и файлом и путём,
BFE>·>Нет. path может быть только путём. Посмотри в словаре значение слова "path".
BFE>Посмотрел:
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.
Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
BFE>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
BFE>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.
Шо?
Re[9]: std::filesystem::copy_file и права
Здравствуйте, 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>
Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
BFE>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
к чему это.
BFE>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.
Шо?
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>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.
Ну. И? Перевожу: одним из компонентов пути может быть файловое имя (filename), а не файл. Т.е. откуда ты придумал, что path может быть файлом — я понятия не имею. Для файлов есть например совсем другой тип — std::FILE. Для определения является ли данное имя обычным файлом (regular file), директорией или чем-то ещё — тебе уже необходимо прочитать содержимое файловой системы по данному пути.
BFE>Там ещё есть интересная таблица. Хочется пожелать удачи авторам std::filesystem в имплантации их библиотеки на всех перечисленных системах...
BFE>Действительно, ведь для ключей "-t и -T" дополнительный код писать не надо.
Шо?