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

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

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

M>Ну да, копируешь на флешку/сетевой каталог/смонтированный vhd образ и уносишь на другой ПК.

Вполне могут учитываться свойства тома

M>Что касается прав, то при создании нового файла их устанавливает (копирует с оригинала) сам процесс. Т.е. если у него есть права на изменение прав, то он же их потом и поменяет на нужные ему.

При создании права создаются по дефолту в зависимости от учетки (или вроде с hTemplateFileб если задан). При копировании права копируются с исходного файла

M>(здесь я исхожу из предположения, что CopyFile просто открывает файл (CreateFile) и копирует контент в новое место).

Это неверное предположение, CreateFile/ReadFile/WriteFile может делать и пользовательский код. Операционная система, я уверен, располагает и другими механизмами. Не уверен, но могу предположить, что бэкап вполне возможно делается без прав доступа к содержимому файла

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

BFE>>Возможна ли ситуация при которой std::filesystem::copy_file скопирует файл, но при этом у процесса нет прав доступа на чтение файла?
ВМ>ну попробуй из под юзера скопировать какой нибудь файл админа на который стоит запрет чтения от левых

Что докажет единичный случай?

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

BFE>>Возможна ли ситуация при которой std::filesystem::copy_file скопирует файл, но при этом у процесса нет прав доступа на чтение файла?
ВМ>ну попробуй из под юзера скопировать какой нибудь файл админа на который стоит запрет чтения от левых

С правами, кстати, ещё смешнее: права файла узнать можно, но вот узнать, может ли приложение открыть файл на чтение — нельзя.

M>>(здесь я исхожу из предположения, что CopyFile просто открывает файл (CreateFile) и копирует контент в новое место).

M>Это неверное предположение, CreateFile/ReadFile/WriteFile может делать и пользовательский код. Операционная система, я уверен, располагает и другими механизмами.

Если интересно, то можно поискать в исходниках w2k/w2k3, которые валялись в интернетах.
(ну или call stack отладчиком посмотреть).

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

Для пофайлового backup/restore обычно используется backup/restore privilege.
Привиллегия назнается группе через локальные политики и дает право читать данные и метаданные в обход прав на файловой системе.
(robocopy например умеет её использовать)

Но в контексте вопроса ТС я не рассматриваю это как копирование без "прав доступа на чтение файла".
Права у процесса есть, просто получены другим путем.

BFE>но вот узнать, может ли приложение открыть файл на чтение — нельзя.

Хм, что ты имеешь в виду (и для какой ОС)?
В общем случае эффективные права зависят от многих факторов, среди которых не только security атрибуты файла, но и полный набор групп в токене процесса (потока).

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

BFE>>но вот узнать, может ли приложение открыть файл на чтение — нельзя.

M>Хм, что ты имеешь в виду (и для какой ОС)?
M>В общем случае эффективные права зависят от многих факторов, среди которых не только security атрибуты файла, но и полный набор групп в токене процесса (потока).

Есть такая функция:
std::filesystem::status
она возвращает
std::filesystem::file_status
у этого типа есть метод
std::filesystem::file_status::permissions
который возвращает значение перечисления std::filesystem::perms, которое перечислением не является, а, как обычно, следуя дебильной практике, является набором флагов.
Как бы там ни было, возможность узнать права на файл можно: ссылка, но что с ними делать изнутри программы? Основываясь на значении флагов узнать, возможно ли открыть файл на чтение/запись, возможно ли скопировать или переместить файл — нет такой возможности.
В std::filesystem всё продумано!

Ну и вот задача: мне надо скопировать файл. Если таргет это symlink или каталог, то они должны быть удалены перед копированием. Мне надо знать пройдёт ли операция копирования до того, как таргет (symlink или каталог) будут удалены. Как это сделать не открывая исходный файл на чтение?

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

BFE>Ну и вот задача: мне надо скопировать файл. Если таргет это symlink или каталог, то они должны быть удалены перед копированием. Мне надо знать пройдёт ли операция копирования до того, как таргет (symlink или каталог) будут удалены. Как это сделать не открывая исходный файл на чтение?

скопировать (под временным именем, в целевую папку) -> удалить старое -> переименовать.
Или с hardlink поиграть, но копирование в любом случае должно быть первое.

Копирование может не пройти и по причинам "сетевое соединение оборвалось" / "место на диске кончилось, хотя 5 миллисекунд назад оно было" и по 100500 других причин.

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

ВМ>>ну попробуй из под юзера скопировать какой нибудь файл админа на который стоит запрет чтения от левых
BFE>С правами, кстати, ещё смешнее: права файла узнать можно, но вот узнать, может ли приложение открыть файл на чтение — нельзя.
Это бессмысленно всё равно. Ну допустим ты это как-то узнал до открытия файла. И что дальше? Какая разница-то? Что с этой информацией можно сделать полезного?

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

BFE>>Ну и вот задача: мне надо скопировать файл. Если таргет это symlink или каталог, то они должны быть удалены перед копированием. Мне надо знать пройдёт ли операция копирования до того, как таргет (symlink или каталог) будут удалены. Как это сделать не открывая исходный файл на чтение?

C>скопировать (под временным именем, в целевую папку) -> удалить старое -> переименовать.
Думал сначала переименовать, а потом удалить таргет, но такой вариант лучше.

Наверное, даже, лучше так: скопировать с временным именем, переименовать таргет, переименовать скопированный файл, удалить переименованный таргет...

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

C>Копирование может не пройти и по причинам "сетевое соединение оборвалось" / "место на диске кончилось, хотя 5 миллисекунд назад оно было" и по 100500 других причин.
Это известно. Ещё и таргет может создаваться, скажем, по таймеру...

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

ВМ>>>ну попробуй из под юзера скопировать какой нибудь файл админа на который стоит запрет чтения от левых
BFE>>С правами, кстати, ещё смешнее: права файла узнать можно, но вот узнать, может ли приложение открыть файл на чтение — нельзя.
·>Это бессмысленно всё равно. Ну допустим ты это как-то узнал до открытия файла. И что дальше? Какая разница-то? Что с этой информацией можно сделать полезного?
Тогда можно удалять таргет, например.

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

BFE>·>Это бессмысленно всё равно. Ну допустим ты это как-то узнал до открытия файла. И что дальше? Какая разница-то? Что с этой информацией можно сделать полезного?
BFE>Тогда можно удалять таргет, например.
Нельзя, конечно, если ты пишешь код с защитой от сбоев. А иначе... с ровно таким же успехом таргет можно удалять и без проверки.

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

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

BFE>Мне надо знать пройдёт ли операция копирования до того, как таргет (symlink или каталог) будут удалены. Как это сделать не открывая исходный файл на чтение?

Хм, тебе прниципиально нужно избежать "лишнего" открытия на чтение?
Так то, файловый дескриптор на чтение (оригинальный файл) и файловый дескриптор на запись/удаление (копия с временным именем) это самый очевидный способ определить есть ли достаточные права.

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

BFE>·>Нельзя, конечно, если ты пишешь код с защитой от сбоев. А иначе... с ровно таким же успехом таргет можно удалять и без проверки.
BFE>При работе с файловой системой от всех возможных сбоев защититься невозможно, насколько я понимаю,
Возможно, конечно. Ну кроме каких-то системных отказов (т.е. железо или баги в драйверах), равзе только. Иначе, как по-твоему СУБД, например, работают?

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

Саракстически смеёшься над std::filesystem, но демонстрируешь непонимание как собственно файловые системы работают.

BFE>По крайней мере я бы ожидал от, скажем, файлового менеджера, что такая проверка делается.
Самое простое — открывает исходный файл на чтение и, если успешно, открывает таргет-файл на запись. Собственно всё. Зачем в принципе делать какие-то проверки перед открытием — я не понимаю.

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

BFE>>Мне надо знать пройдёт ли операция копирования до того, как таргет (symlink или каталог) будут удалены. Как это сделать не открывая исходный файл на чтение?
M>Хм, тебе прниципиально нужно избежать "лишнего" открытия на чтение?

Нет, просто как-то неожиданно, что даже зная права на файл невозможно их никак сопоставить с теми операциями, которые позволены приложению.

M>Так то, файловый дескриптор на чтение (оригинальный файл) и файловый дескриптор на запись/удаление (копия с временным именем) это самый очевидный способ определить есть ли достаточные права.
Если бы я сам, используя функциональность ввода-вывода занимался копированием файлов, то так бы и было, но если есть std::filesystem, то разумно ожидать наличие функции, типа, std::filesystem::access(path), которая возвращает набор прав, которыми обладает приложение по отношению к указанному файлу. Есть разумная причина, почему такой функции нет?

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

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

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

BFE>>·>Нельзя, конечно, если ты пишешь код с защитой от сбоев. А иначе... с ровно таким же успехом таргет можно удалять и без проверки.
BFE>>При работе с файловой системой от всех возможных сбоев защититься невозможно, насколько я понимаю,
·>Возможно, конечно. Ну кроме каких-то системных отказов (т.е. железо или баги в драйверах), равзе только. Иначе, как по-твоему СУБД, например, работают?
А причём тут СУБД? В работу СУБД вмешиваются сторонние приложения, удаляют, подменяют файлы базы данных?

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

·>Саракстически смеёшься над std::filesystem, но демонстрируешь непонимание как собственно файловые системы работают.
Я не очень глубоко знаю как работают файловые системы, но знаю, что они бывают совершенно разные. Однако речь не про файловые системы, а про функциональность std::filesystem.

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

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

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

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

BFE>·>Возможно, конечно. Ну кроме каких-то системных отказов (т.е. железо или баги в драйверах), равзе только. Иначе, как по-твоему СУБД, например, работают?
BFE>А причём тут СУБД? В работу СУБД вмешиваются сторонние приложения, удаляют, подменяют файлы базы данных?
Какие-нибудь тулзы субд и такое могут.

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

BFE>·>Саракстически смеёшься над std::filesystem, но демонстрируешь непонимание как собственно файловые системы работают.
BFE>Я не очень глубоко знаю как работают файловые системы, но знаю, что они бывают совершенно разные. Однако речь не про файловые системы, а про функциональность std::filesystem.
Функциональность std::filesystem соответствует тому как работают файловые системы.

BFE>·>Самое простое — открывает исходный файл на чтение и, если успешно, открывает таргет-файл на запись. Собственно всё. Зачем в принципе делать какие-то проверки перед открытием — я не понимаю.
BFE>А я не понимаю. зачем мне вообще что-то открывать,
_Тебе_? Я тоже не понимаю. Ты задал вопрос о том как могут работать файловые менеджеры.

BFE>если я не собираюсь заниматься вводом-выводом.
Ты уж определись. Удаление файла — это тоже ввод-вывод.

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

BFE>>·>Возможно, конечно. Ну кроме каких-то системных отказов (т.е. железо или баги в драйверах), равзе только. Иначе, как по-твоему СУБД, например, работают?
BFE>>А причём тут СУБД? В работу СУБД вмешиваются сторонние приложения, удаляют, подменяют файлы базы данных?
·>Какие-нибудь тулзы субд и такое могут.
Прямо во время работы?

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

BFE>>·>Саракстически смеёшься над std::filesystem, но демонстрируешь непонимание как собственно файловые системы работают.
BFE>>Я не очень глубоко знаю как работают файловые системы, но знаю, что они бывают совершенно разные. Однако речь не про файловые системы, а про функциональность std::filesystem.
·>Функциональность std::filesystem соответствует тому как работают файловые системы.
Ну, я бы так не сказал. Хотя, тут, конечно, вопрос: что значит "соответствуют"?

BFE>>·>Самое простое — открывает исходный файл на чтение и, если успешно, открывает таргет-файл на запись. Собственно всё. Зачем в принципе делать какие-то проверки перед открытием — я не понимаю.
BFE>>А я не понимаю. зачем мне вообще что-то открывать,
·>_Тебе_? Я тоже не понимаю. Ты задал вопрос о том как могут работать файловые менеджеры.
Исходный вопрос о другом.

BFE>>если я не собираюсь заниматься вводом-выводом.
·>Ты уж определись. Удаление файла — это тоже ввод-вывод.
Хорошо: мне не нужны операции с содержимым файлов.

BFE>но если есть std::filesystem, то разумно ожидать наличие функции, типа, std::filesystem::access(path), которая возвращает набор прав, которыми обладает приложение по отношению к указанному файлу. Есть разумная причина, почему такой функции нет?

На уровне API OS (MS Windows) такие функции есть. Но работа с ними сложнее.
Т.е. возможно различие в поведении такого API для разных OS осложняет включение его в std::filesystem.
IMHO, если нужна нетривиальная работа с файловой системой, то лучше сразу брать системное API.

·>>Ты уж определись. Удаление файла — это тоже ввод-вывод.
BFE>Хорошо: мне не нужны операции с содержимым файлов.

ну тогда открытие файлового дескриптора это ещё не операция с содержимым.
И между прочим удаление и переименование тоже предполагает открытие файлового дескриптора (хотя возможно это и специфично для ОС).
Более того — для того, чтобы прочитать права на файл тебе уже нужно открыть дескриптор файла или родительского каталога.

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

BFE>>>Объясните, почему кажется?
BFE>·>Не надо так делать. Если тебе надо сохранить целостность, то обычно делают через переименование. Скопировать файл рядом с новым именем и переименовать, перезаписав старое. Если таргет можно терять, то просто открывай его на перезапись после того, как открылся исходный файл на чтение.
BFE>Если таргет — каталог, а на его место надо записать файл с тем же именем, то так сделать не получится.
Ок. Тогда: Скопировать файл рядом с новым именем и переименовать, перезаписав старое. Если переименование обломалось, удалить старое, переименовать опять.

BFE>>>Я не очень глубоко знаю как работают файловые системы, но знаю, что они бывают совершенно разные. Однако речь не про файловые системы, а про функциональность std::filesystem.
BFE>·>Функциональность std::filesystem соответствует тому как работают файловые системы.
BFE>Ну, я бы так не сказал. Хотя, тут, конечно, вопрос: что значит "соответствуют"?
Мне неизвестна файловая система в которой есть операция операция "проверить можно ли открыть файл на чтение без открытия файла". Почему ты хочешь, чтобы такое было в std::filesystem — неясно. И главное — как оно в принципе может быть реализовано и для чего использовано (написание бажных ненадёжных программулек не в счёт).

BFE>Исходный вопрос о другом.
Ну ты почему-то ожидал что-то странное от файлового менеджера. Я пояснил, что твои ожидания какие-то странные.

BFE>>>если я не собираюсь заниматься вводом-выводом.
BFE>·>Ты уж определись. Удаление файла — это тоже ввод-вывод.
BFE>Хорошо: мне не нужны операции с содержимым файлов.
А что по-твоему делает операция копирования файла?

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

BFE>>>Нет, просто как-то неожиданно, что даже зная права на файл невозможно их никак сопоставить с теми операциями, которые позволены приложению.
BFE>·>Так права могут и быть, но файл может быть эксклюзивно залочен другим процессом, например.
BFE>Может. А ещё его может удалить другой процесс. Создать заново. Писать во время копирования. А в некоторых системах, даже удалить во время исполнения. Не знаю, можно ли поменять права доступа во время копирования, но, наверное, такое тоже возможно. И что с того? Ситуация, при которой два процесса одновременно работают с одним и тем же файлом довольно редкая по сравнению с той, когда можно считать, что есть ровно один процесс работающий с файловой системой и этот наш процесс. Многие файловые менеджеры работают именно так — не отслеживают изменения производимые другими процессами.
Вот поэтому и не отслеживают, потому что бессмысленно. Просто делают заданную задачу и обрабатывают ошибочные результаты, запрашивают интерактивно что делать дальше.

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

·>Ок. Тогда: Скопировать файл рядом с новым именем и переименовать, перезаписав старое. Если переименование обломалось, удалить старое, переименовать опять.
Да. я буду делать именно так, но тут надо понимать, что это не оптимальный вариант, так как в этом случае может не хватить места.

·>Мне неизвестна файловая система в которой есть операция операция "проверить можно ли открыть файл на чтение без открытия файла".
Ладно, я переформулирую вопрос. Я не хотел спрашивать "можно ли открыть файл на чтение без открытия файла". Я спрашиваю: есть ли у исполняемого кода такие права, что позволяют открыть указанный файл на чтение.

·>Почему ты хочешь, чтобы такое было в std::filesystem — неясно. И главное — как оно в принципе может быть реализовано и для чего использовано (написание бажных ненадёжных программулек не в счёт).
Надо просто сравнить права, с которыми исполняется приложение, с правами файла. Что в этом сложного и зачем при этом открывать файл?

·>А что по-твоему делает операция копирования файла?
Копирует файл. Как она это делает — дело десятое и может зависить от чего угодно: от файловой системы, от операционной системы, от драйвера, от устройства. ЕМНИП DVD-ROM можно было организовать так, что при записи одинаковых файлов создаётся "hard link" вместо копирования файла, файловая система поддерживала. Я вполне могу представить файловое хранилище в облаке, которое просто увеличивает счётчик у файла и прописывает имя в каталог. Поэтому для меня даже копирование файла и копирование содержимого файла — это две разные операции, не говоря уж о вводе-выводе.

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

·>Вот поэтому и не отслеживают, потому что бессмысленно. Просто делают заданную задачу и обрабатывают ошибочные результаты, запрашивают интерактивно что делать дальше.
Обычно, когда я копирую файл, а в указанном каталоге уже есть файл с таким именем, то файловый менеджер спрашивает подтверждения на перезапись. Это не обработка ошибочной ситуации и это обычное поведение.
Впрочем, у меня есть лучше пример. Если от лица пользователя с правами root пытаться перезаписать файлы, что принадлежат другому пользователю, то ЕМНИП некоторые утилиты выдают предупреждение что-то вроде: эти файлы принадлежат не вам, уважайте права других, вы уверены, что хотите их перезаписать? Вполне разумный запрос. Как реализовать такую функциональность используя std::filesystem ?

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

M>На уровне API OS (MS Windows) такие функции есть. Но работа с ними сложнее.
M>Т.е. возможно различие в поведении такого API для разных OS осложняет включение его в std::filesystem.
Ну, если есть права, то и функции должны быть.

M>IMHO, если нужна нетривиальная работа с файловой системой, то лучше сразу брать системное API.
Вот как раз этого хочется избежать.

BFE>Ну, если есть права, то и функции должны быть.

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

Напомню также, что права на ФС могут быть настроена так, что у пользователя нет прав на чтение пермиссий, но есть права на чтение контента файла.
(такое делается из соображений безопасности)

Простой std::fopen кратно проще и надежнее.

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

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

И, кстати, твоя хотелка удалять диру — необычна. Известные мне файловые менеджеры это не делают. Либо копируют внутрь диры, либо отказывается выполнять операцию — удаляй диру явно, если так хочется. Например cp говорит "cannot overwrite directory with non-directory".

BFE>Впрочем, у меня есть лучше пример. Если от лица пользователя с правами root пытаться перезаписать файлы, что принадлежат другому пользователю, то ЕМНИП некоторые утилиты выдают предупреждение что-то вроде: эти файлы принадлежат не вам, уважайте права других, вы уверены, что хотите их перезаписать? Вполне разумный запрос. Как реализовать такую функциональность используя std::filesystem ?
Насколько я знаю, в std нет возможности определения овнера. Только rwx атрибуты можно поглядеть. Так что без системно-зависимых api в Плюсах имхо не обойтись.

M>>Оффтоп. std::filesystem — это какой-то выкидыш здравого смысла, стараюсь держаться от него подальше
BFE>Да, у меня тоже сложилось впечатление, что авторы ничего сложного с её помощью написать даже не пытались.

А поясните, почему?
Я касался ее не очень подробно, но для простых вещей вроде норм было.

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

BFE>>Ну, если есть права, то и функции должны быть.
M>В расчёте эффективных прав много нюансов.

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

Так как все эти утверждения полны внутренних противоречий, я ничего не понимаю из того, что здесь написано.
1) Вы пишите, что сложно реализовать такую функциональность. Ну так библиотека для того и нужна, чтобы реализовывать сложную функциональность. Простую функциональность можно и в прикладном коде написать.
2) Вы пишите, что "права на ФС могут быть настроена так, что у пользователя нет прав на чтение пермиссий, но есть права на чтение контента файла". Может. И что? Это ведь не то, о чём я пишу.
Функцией в одну строчку:

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

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

M>Простой std::fopen кратно проще и надежнее.
"Настоящие герои всегда идут в обход"

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

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

·>И, кстати, твоя хотелка удалять диру — необычна. Известные мне файловые менеджеры это не делают. Либо копируют внутрь диры, либо отказывается выполнять операцию — удаляй диру явно, если так хочется. Например cp говорит "cannot overwrite directory with non-directory".
Да, я понимаю, что хотелка заменить директорию файлом необычна. Я понимаю, обоснованность отсутствия такой возможности у интерактивных утилит.

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

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

BFE>·>В хорошо спроектированном софте обработка ошибочных результатов — это обычное поведение.
BFE>Согласен, но я не считаю, что запрос на перезаписывание файла является обработкой ошибки.
Запрос на перезаписывание файла может не выполниться и выдать ошибочный результат. Его обычно надо обрабатывать. Даже если ты перед самим запросом ты всё десять раз перепроверил и вроде как ожидаешь, что всё должно сработать. Поэтому неясно зачем запрашивать какие-то права и делать другие танцы перед запросом.

BFE>·>Насколько я знаю, в std нет возможности определения овнера. Только rwx атрибуты можно поглядеть. Так что без системно-зависимых api в Плюсах имхо не обойтись.
BFE>Так об этом я и пишу.
По-моему ты писал, что тебе надо проверить "права, что позволяют открыть указанный файл на чтение" — это можно в std, для этого не нужно определять овнера. Но это не нужно делать для решения задачи, которую я понял как "перезаписать файл". Я видимо совершенно перестал понимать какую же задачу ты пытаешься решить.

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

BFE>>Да, у меня тоже сложилось впечатление, что авторы ничего сложного с её помощью написать даже не пытались.
DTF>А поясните, почему?
DTF>Я касался ее не очень подробно, но для простых вещей вроде норм было.

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

Или, например, std::filesystem::path не различает имя файла и имя каталога. Вернее так: имя файла и имя директории — это один и тот же объект: std::filesystem::path. Это не удобно использовать. Было бы логично иметь три типа объектов: путь, имя файла и путь_с_файлом.

И др. в том же духе.

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

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

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

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>

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-совместимая обертка для упрощения написания кросплатформенного кода в _простых_ случаях.

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

BFE>Возможна ли ситуация при которой std::filesystem::copy_file скопирует файл, но при этом у процесса нет прав доступа на чтение файла?

Это, наверное, зависит от системы.

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

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

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

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

Я думаю, этой хрени хватит, например, чтобы написать архиватор.

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

Я подозреваю, что в UNIX этот итератор просто зовёт readdir. readdir не завершится с ошибкой от того, что другой процесс создал или удалил файл. Но может не заметить изменений в директории.

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

Итерирование директории, в которой постоянно происходит какая-то жизнь, даже на уровне системных вызовов нетривиально и нуждается в тщательном продумывании.

К тому, что на уровне сисколов непросто, стандартная библиотека вряд ли сможет приделать более простую абстракции. К тому же, стандартная библиотека должна изображать из себя что-то нейтральное по отношению к ОС.

BFE>Или, например, std::filesystem::path не различает имя файла и имя каталога. Вернее так: имя файла и имя директории — это один и тот же объект: std::filesystem::path. Это не удобно использовать. Было бы логично иметь три типа объектов: путь, имя файла и путь_с_файлом.

UNIX их тоже не различает. Нужно отдельно stat говорить. Становится понятно, откуда уши торчат

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

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

Ты сейчас предлагаешь способ именования файлов, не похожий ни на одну существующую операционную систему.

Это означает, если его использовать, в любой ОС будет неудобно. Хотя, наверное, и справедливо, никому не будет обидно.

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

BFE>>>>Зачем в стандарт языка тащить стандарт API системы?
BFE>>·>posix — это не api конкретной системы.
BFE>>Да.

·>Т.е. твоя идея std::posix_filesystem — не состоятельна и "Зачем в стандарт языка тащить стандарт API системы" — дурацкий вопрос.
Почему дурацкий? std::filesystem не является универсальной. Так? Она годится только для posix совместимых файловых систем. Тогда почему она не называется std::posix_filesystem ?

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++, а не какой-то другой?
·>Понятия не имею. А какая разница?
Проблема в том, что библиотека std::filesystem получилась весьма специфичной, да ещё и кривой.

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 является неотъемлемой часть языка?
То, что все остальные являются универсальными, а std::filesystem — нет.

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>>Да неужели?
·>Ну да.
И как эти заморочки решены в std::filesystem ?

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

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

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

BFE>>я знаю.
·>А в чём тогда претензия?
Почему все эти специфичные для posix систем типы не implementation-defined ? Как их поддерживать для FAT систем?

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.
Нет.
·>Вот только почему-то ты хочешь случайно расставленные / с неясно какой целью. Добавляй их сам.
Не случайно.
·> Я логику не улавливаю.
Что вам не понятно?
Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.

·>Покажи решение на ЯП/либе, в которых, есть по-твоему правльно реализованный path.

Это вы грозились мне её написать.

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

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

BFE>>rust уже стандартизовали?
·>Не знаю. А какая разница?
Для меня есть большая разница. Я стараюсь избегать использование языков без стандарта.

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

BFE>>>Да.

BFE>·>Т.е. твоя идея std::posix_filesystem — не состоятельна и "Зачем в стандарт языка тащить стандарт API системы" — дурацкий вопрос.
BFE>Почему дурацкий? std::filesystem не является универсальной. Так? Она годится только для posix совместимых файловых систем.
Даже какой-нибудь банальный std::map тоже не является универсальным. И что?

BFE> Тогда почему она не называется std::posix_filesystem ?
Я уже отвечал на этот вопрос. Потому что она умеет не только posix, но и в winapi например.

BFE>>>Остальные тоже тоже как-то стандартизованы отдельными документами.
BFE>·>И что?
BFE>Для них для всех надо добавлять классы в С++ стандарт?
Нет, не надо.

BFE>·>Не знаю. А какая разница? Разбираться лень, но например thread по сути поделие для замены posix-тредов.
BFE>·>Кстати, а в каком отдельном стандарте описано std::filesystem?
BFE>Видно, что вам лень разбираться.
Потому что это твоё словоблудие про стандарты, ты и парься.

BFE>>>По какому критерию выбран именно этот стандарт для добавления в C++, а не какой-то другой?
BFE>·>Понятия не имею. А какая разница?
BFE>Проблема в том, что библиотека std::filesystem получилась весьма специфичной, да ещё и кривой.
Допустим. Так причём тут критерии выбора?

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

BFE>>>·>Изучай доки как файловая система работает. Задача std — обеспечить стандартизованый доступ к API файловой системы, а то как она функционирует — опредеяется реализацией фс.
BFE>>>Скажите, какая цель создания библиотеки std::filesystem ?
BFE>·>Такая же как у fstream, std::cin, std::cout, atomic, chrono, mutex, random, thread, locale, map, vector, string.
BFE>Не похоже.
В чём не похоже?

BFE>>>·>Это, кстати, заморочки win/ntfs, насколько я понял. Если у тебя где-то под рукой есть Винда, можешь потетстить.
BFE>>>Да неужели?
BFE>·>Ну да.
BFE>И как эти заморочки решены в std::filesystem ?
В доке написано же: "Portable code should use (3,4)".

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

BFE>>>Уверен, что если провести опрос, то окажется что более 90% программистов никогда в жизни не работали с такими файлами именно как с файлами.
BFE>·>И что?
BFE>std::filesystem их поддерживает?
Да, насколько я знаю.

BFE>>>я знаю.
BFE>·>А в чём тогда претензия?
BFE>Почему все эти специфичные для posix систем типы не implementation-defined ? Как их поддерживать для FAT систем?
Не возвращать значения этих типов.

BFE>·>Это просто parent_path и filename.
BFE>Нет.
Ну ещё возможно has_filename или ещё какой-нибдуь has_X.

BFE>·> Я логику не улавливаю.
BFE>Что вам не понятно?
BFE>Возвращаемое значение должно быть вида {путь, имя}, где имя — это последнее имя в pathName, а путь — это то, что перед ним. Имя должно быть пустым, если его нельзя вычленить.
Ну, например, в пути "a/" — последнее имя (ака filename) отсутствует, его нельзя вычленить. Та же ситуация, что и для "/a/" и "/". Но ты выше захотел внезапно "a/" -> {"", "a"}. Где у тебя логика?

BFE>·>Покажи решение на ЯП/либе, в которых, есть по-твоему правльно реализованный path.
BFE>

Это вы грозились мне её написать.
Я утверждал, что твою логику (если она действительно есть) можно написать на std::filesystem. Твой тезис был, что он слишком крив. Вот только что же ты считаешь некривым — ты тщательно скрываешь.

BFE>·>В данных путях его нет, has_filename возвращает false.
BFE>Значит, таки, определить является ли имя файлом или каталогом можно по виду пути?
У тебя со зрением плохо? Ещё раз. "filename" это не то же самое что "file". И про каталоги у меня речи не шло. Ещё раз: это путь без имени файла. И ещё раз напомню: каталог — это тоже файл.

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

BFE>>>rust уже стандартизовали?
BFE>·>Не знаю. А какая разница?
BFE>Для меня есть большая разница. Я стараюсь избегать использование языков без стандарта.
Это твои личные заморочки. Решай этот вопрос с личным психологом.

	От:	B0FEE664
	Дата:	10.07.25 17:59
	Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	10.07.25 18:01
Оценка:	-2

	От:	B0FEE664
	Дата:	10.07.25 18:55
	Оценка:

	От:	m2user
	Дата:	10.07.25 19:06
	Оценка:

От:	Великий Мессия	google
Дата:	10.07.25 19:14
Оценка:

	От:	Chorkov
	Дата:	11.07.25 09:22
	Оценка:	6 (1) +3

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

	От:	DTF
	Дата:	14.07.25 10:01
	Оценка: