C'est la réponse que j'ai obtenue de Silje Johansen - Ingénieur Support - Trolltech ASA (en mars 2008 cependant)
Cependant. la complexité de l'inclusion des paramètres locaux et de trouver une façon unifiée d'interroger les systèmes de fichiers sur Linux/Unix à propos de leur fonctionnalité est proche de l'impossible.
Cependant, à ma connaissance, toutes les applications que je connais ignorent ce problème.
(à lire : ils ne vont pas le mettre en œuvre)
Boost ne résout pas non plus le problème, ils donnent seulement une notion vague de la longueur maximale des chemins, en particulier si vous voulez être multiplateforme. Autant que je sache, beaucoup ont essayé et ont échoué à résoudre ce problème (du moins en théorie, en pratique il est certainement possible d'écrire un programme qui crée des noms de fichiers valides dans la plupart des cas.
Si vous souhaitez le mettre en œuvre vous-même, il pourrait être utile de prendre en compte quelques choses qui ne sont pas immédiatement évidentes, comme :
Complications avec les caractères non valides
La différence entre les limitations du système de fichiers et les limitations du système d'exploitation et du logiciel. Par exemple, Windows Explorer, que je considère comme faisant partie du système d'exploitation Windows, ne prend pas en charge pleinement le NTFS. Des fichiers contenant ':' et '?', etc... peuvent résider sans problème sur une partition ntfs, mais Explorer s'étouffe juste avec eux. Mis à part cela, vous pouvez jouer la prudence et utiliser les recommandations de Boost Filesystem.
Complications avec la longueur du chemin
Le deuxième problème partiellement abordé par la page de boost est la longueur du chemin complet. La seule chose certaine à ce moment est qu'aucune combinaison OS/système de fichiers ne supporte des longueurs de chemin indéfinies. Cependant, des affirmations comme "les chemins maximum de Windows sont limités à 260 caractères" sont fausses. L'API unicode de Windows vous permet en fait de créer des chemins allant jusqu'à 32,767 caractères utf-16. Je n'ai pas vérifié, mais j'imagine qu'Explorer s'étouffe de la même manière, ce qui rendrait cette fonctionnalité complètement inutile pour les logiciels ayant des utilisateurs autres que vous-même (d'un autre côté, vous préférerez peut-être que votre logiciel ne s'étouffe pas en chœur).
Il existe une ancienne variable qui répond au nom de PATH_MAX, qui semble prometteuse, mais le problème est que PATH_MAX simplement n'est pas.
Pour finir sur une note constructive, voici quelques idées sur des façons possibles de coder une solution.
- Utilisez des définitions pour créer des sections spécifiques aux OS. (Qt peut vous aider avec cela)
- Utilisez les conseils donnés sur la page de boost et la documentation des OS et des systèmes de fichiers pour décider des caractères non valides
- Pour la longueur du chemin, la seule idée réalisable qui me vient à l'esprit est une approche d'essai et d'erreur avec un arbre binaire en utilisant la gestion d'erreurs de l'appel système pour vérifier une longueur de chemin valide. C'est plutôt distant, mais cela pourrait être la seule possibilité d'obtenir des résultats précis sur une variété de systèmes.
- Devenez bon en gestion d'erreurs élégante.
J'espère que cela vous a donné des idées.