Encore un procès d'intention un peu facile ;-).
- Pour les "fous" aimant les répertoires de plus de 260 caractères (noter le mot, ce n'est pas octets), certains outils ont du mal sous Windows, pas d'autres (ça dépend de savoir si ils utilisent l'API étendue ou pas). Donc avec Windows, tu peux si tu codes pour. Visual Studio n'est pas prévu, mais tu peux faire ton logiciel compatible si tu veux.
- Pour les utilisateurs Linux... Ben ce n'est jamais possible! Ext4, Btrfs, ZFS... sont tous limités à 255 octets (noter le mot, ça veut dire qu'on peut tomber à une limite de 63 caractères si ont s'amuse avec des caractères dans la plage très étendue Unicode, youpi!)
Qui est le pire? J'ai l'impression que vous n'êtes pas trop au point sur vos connaissances des limites de votre OS préféré ;-)
ne pas pouvoir stocker un nom de fichier de 64 caractères en 2016, c'est moins top que de ne pas pouvoir stocker un nom de fichier de 250 caractères en 2016.
$ echo a >᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿
marche sous ligne de commande Windows (qui est le soucis pour ton bug report, utilisé l'API limitant à 260 caractères), pas sous Linux (qui limite à 255 octets, j'ai pris un caractères sur 2 octets ayant la flemme d'en chercher un sur 4 octets, bam la honte de ne pas pouvoir stocker ça).
PS : bon, à décharge de Windows, Windows dit "file not found" pas logique de tout, Linux dit "File name too long" soit le bon message. 1 point pour Linux. Et surtout Linux sait afficher le nom en ligne de commande pas de "?", 2 points pour Linux (et des importants, plus que la limite à 255 octets, la phrase au dessus était surtout pour troller :) )
[^] # Re: choix de dossier
Posté par Zenitram (site web personnel) . En réponse à la dépêche LibreSSL 2.3.3. Évalué à -2. Dernière modification le 12 avril 2016 à 22:42.
Encore un procès d'intention un peu facile ;-).
- Pour les "fous" aimant les répertoires de plus de 260 caractères (noter le mot, ce n'est pas octets), certains outils ont du mal sous Windows, pas d'autres (ça dépend de savoir si ils utilisent l'API étendue ou pas). Donc avec Windows, tu peux si tu codes pour. Visual Studio n'est pas prévu, mais tu peux faire ton logiciel compatible si tu veux.
- Pour les utilisateurs Linux... Ben ce n'est jamais possible! Ext4, Btrfs, ZFS... sont tous limités à 255 octets (noter le mot, ça veut dire qu'on peut tomber à une limite de 63 caractères si ont s'amuse avec des caractères dans la plage très étendue Unicode, youpi!)
Qui est le pire? J'ai l'impression que vous n'êtes pas trop au point sur vos connaissances des limites de votre OS préféré ;-)
ne pas pouvoir stocker un nom de fichier de 64 caractères en 2016, c'est moins top que de ne pas pouvoir stocker un nom de fichier de 250 caractères en 2016.
marche sous ligne de commande Windows (qui est le soucis pour ton bug report, utilisé l'API limitant à 260 caractères), pas sous Linux (qui limite à 255 octets, j'ai pris un caractères sur 2 octets ayant la flemme d'en chercher un sur 4 octets, bam la honte de ne pas pouvoir stocker ça).
PS : bon, à décharge de Windows, Windows dit "file not found" pas logique de tout, Linux dit "File name too long" soit le bon message. 1 point pour Linux. Et surtout Linux sait afficher le nom en ligne de commande pas de "?", 2 points pour Linux (et des importants, plus que la limite à 255 octets, la phrase au dessus était surtout pour troller :) )