Limitação max_path em boost.filesystem

Question

Quero usar o Boost.Filesystem Library para manipular caminhos, arquivos e diretórios. Minha pergunta é: os caminhos são mais longos que o max_path suportado?

Eu sei que no Win32API temos uma solução alternativa "? ", Mas não é apoiada por funções básicas como PathAppend e Pathcombine.

Então, estou procurando qualquer informação útil sobre max_path e boost.fs.

Obrigado

UPD: Eu me importo com todas as operações, como o Append Append, o Path Combine, etc (eu tenho essas funções no Win32API, mas elas não funcionam com caminhos por mais tempo que Max_Path), por exemplo, CreateFilew e DeleteFilew, ambos suportam caminhos por mais tempo que Max_Path. Pode ser um substituto para as funções de utilidade Win32API, como as encontradas em Shlwapi e Shell32, que geralmente não suportam caminhos longos

Answer 1

A verdade é que o Windows suporta caminhos de qualquer comprimento e qualquer caminho pode ser convertido em string no Windows. Adicionando \\?\ é necessário nesse caso, mas essa é a parte de "fazer uma string a partir de um determinado caminho".

Afaik, Boost :: FileSystem faz isso errado no Windows.

Não sei se uma correção está planejada. Ver isto sobre como isso deve ser feito.

Answer 2

Você pode manipular qualquer comprimento da sequência do caminho do sistema de arquivos com ou sem boost.filesystem.

Max_path são as restrições das APIs de arquivo do Windows. Isto é, você não pode passar a sequência de caminho muito longo para as APIs do Windows.

Por exemplo, remova a função do Boost.Filesystem falhará com mais tempo que Max_Path Length Path. Você deseja que o boost.filesystem faça algo como alterar o diretório atual e usar o caminho relativo para impedir a restrição max_path? Eu não acho que seja possível.

EDITADO

Porque o boost.Filesystem implementado na sequência C ++, você não precisa se preocupar com o comprimento do caminho. O Boost.Filesystem fornece não apenas os métodos de manipulação da string do caminho, mas também os métodos de manipulação do sistema de arquivos. Você deve evitar métodos de sistema de arquivos se o caminho resultante for muito longo.

Não sei se o Boost.Filesystem suporta o caminho Unicode Win32, mas você pode converter o caminho final do ANSI para o caminho Unicode antes de chamar as APIs do arquivo Win32.