ЕМ>Сейчас вот приспичило, и с изумлением обнаружил, что ни в винде, ни в унихах, ни в сишной библиотеке нет функций, принимающих путь, и возвращающих тоже путь
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сейчас вот приспичило, и с изумлением обнаружил, что ни в винде, ни в унихах, ни в сишной библиотеке нет функций, принимающих путь, и возвращающих тоже путь. И из хэндлов, возвращаемых findfirst/FindFirstFile, невозможно добыть путь к каталогу, в котором они ищут, хотя там он заведомо известен.
Вот смотри. Допустим, тебе надо обойти дерево, в котором 100500 миллионов файлов.
И допустим, у тебя крутая удобная обходилка, которая сама умеет шляться по вложенным директориям и всякое такое.
Этой обходилке, для каждого имени надо узнать, что это такое (файл, директория, символическая ссылка и т.п.), Значит, на каждое найденное имя она скажет stat() (или вендовый его налог). Тебе тоже надо знать что-то про файл, значит и ты тоже скажешь stat().
Если у тебя файлов 100500 миллионов штук, то два раза stat говорить не хотелось бы.
В Go-ной библиотеке изначально была обходилка, как ты любишь. С именами на входе и на выходе. Потом добавили такую, более си-подобную, для производительности, когда файлов шибко много. В Go-шную библиотеку просто так чего попало не добавляют. Значит, кому-то сильно приспичило.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сейчас вот приспичило, и с изумлением обнаружил, что ни в винде, ни в унихах, ни в сишной библиотеке нет функций, принимающих путь, и возвращающих тоже путь. И из хэндлов, возвращаемых findfirst/FindFirstFile, невозможно добыть путь к каталогу, в котором они ищут, хотя там он заведомо известен.
ЕМ>Это что ж получается — все эти утилиты сами выделяют путь из исходного шаблона, а затем комбинируют его с именами, возвращаемыми функциями поиска? Как-то странно для столь типовой операции.
Я много лет жил без этой "типовой" операции. Когда приспичило — написал один раз свою обёртку, и теперь много лет использую её.
σ>>Вообще, пути — вещь довольно бесполезная, т.к. это путь к TOCTOU-багам
ЕМ>То есть, glob сделали зря?
Это функция из 80-х и из Unix, который создавался в «статичные» времена
Ну ок, вряд ли glob используют в сценарии когда файлы могут создаваться/удаляться параллельно с вызовом/обработкой результата glob, так что пути здесь сойдут
Так как и в унихах, и в винде есть хренова гора утилит, принимающих шаблонный путь к файлу, но не поддерживающих поиска в подкаталогах, я всю жизнь искренне полагал, что существуют и соответствующие стандартные функции. Как-то так сложилось, что и findfirst, и FindFirstFile мне до сих пор приходилось использовать только для перебирания файлов в известном каталоге, а такого, чтоб на входе был готовый путь, ни разу делать не приходилось.
Сейчас вот приспичило, и с изумлением обнаружил, что ни в винде, ни в унихах, ни в сишной библиотеке нет функций, принимающих путь, и возвращающих тоже путь. И из хэндлов, возвращаемых findfirst/FindFirstFile, невозможно добыть путь к каталогу, в котором они ищут, хотя там он заведомо известен.
Это что ж получается — все эти утилиты сами выделяют путь из исходного шаблона, а затем комбинируют его с именами, возвращаемыми функциями поиска? Как-то странно для столь типовой операции.
Здравствуйте, Pzz, Вы писали:
Pzz>Этой обходилке, для каждого имени надо узнать, что это такое (файл, директория, символическая ссылка и т.п.), Значит, на каждое найденное имя она скажет stat() (или вендовый его налог). Тебе тоже надо знать что-то про файл, значит и ты тоже скажешь stat().
Pzz>Если у тебя файлов 100500 миллионов штук, то два раза stat говорить не хотелось бы.
Зачем два раза говорить stat, почему обходилка не может возвращать то, что ей вернул stat?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это что ж получается — все эти утилиты сами выделяют путь из исходного шаблона, а затем комбинируют его с именами, возвращаемыми функциями поиска? Как-то странно для столь типовой операции.
То, что путь полный не возвращается это очевидно — для этого той же FindFirstFile/FindNextFile пришлось бы аллокировать буфер под строку полного пути, а так возвращается только cFileName в WIN32_FIND_DATA максимальным размером MAX_PATH.
ЕМ>Сейчас вот приспичило, и с изумлением обнаружил, что ни в винде, ни в унихах, ни в сишной библиотеке нет функций, принимающих путь, и возвращающих тоже путь
Вообще, пути — вещь довольно бесполезная, т.к. это путь к TOCTOU-багам
Здравствуйте, TheBeginner, Вы писали:
TB>То, что путь полный не возвращается это очевидно — для этого той же FindFirstFile/FindNextFile пришлось бы аллокировать буфер
FindFirstFile этого делать как раз не нужно — это не ее задача. У этой функции минимально необходимая функциональность для использовании в совершенно разных ситуациях.
Здесь речь о том, что ситуация "получить от пользователя путь с шаблонными символами в имени файла, и перебрать все подходящие под него файлы" является типичной, поскольку это стандартное поведение многих системных утилит и в унихах, и в винде, при этом обход дерева поддерживают далеко не все. Поэтому логично было бы иметь в системе готовое средство. Но даже в унихах его очень долго не было, а в винде его нет до сих пор — каждый городит свою реализацию одного и того же.
И из хэндлов, возвращаемых findfirst/FindFirstFile, невозможно добыть путь к каталогу, в котором они ищут, хотя там он заведомо известен.
