Bonjour,
 
Tous les OS ont leur limitations dans le nommage des fichiers. Qu'elle soit au niveau du système de fichier, du VFS ou des applications, ces limitations ne sont pas les mêmes partout et posent souvent des problèmes.
 
Le cas le plus fréquent qu'il m'est donné de voir est l'utilisation de volumes réseau SMB sur Macintosh. Mac OS étant particullièrement permissif, des erreurs surviennent lors d'opérations sur des systèmes de fichier distants. Aucun message explicite n'onforme l'utilisateur de la nature du problème et peu d'entre eux savent le regler. Resultat : des sociétés de maintenance déconseillent l'usage de NAS ou de serveurs autres que Mac OS à leurs clients.
 
J'aurais donc besoin d'avis et d'aide afin de trouver une piste pour regler au moins partiellement le problème.
 
Quelles sont les limitations de toutes les combinaisons courrantes d'OS/FS ? Quelles concessiosn peut on faire pour s'aligner sur le plus grand nombre ?
 
Merci pour votre aide

Limitations connues
 
Mac OS (toutes versions) / (tous FS):  carractère ":" interdit
Mac OS X (toutes versions) / (tous FS) : carractère "." en début de nom réservé à l'OS, masqué par le finder
Mac OS Classic / HFS+ :, 31 carractères max
Mac OS X / FAT32 : carractères "/\:"

La reponse est 42

Sinon, pour les nom de fichiers, je sais pas, mais je pense que le charset en uft-8 est partout, il me semble preferable de l'utiliser.

Edit: et sans espace

les espaces me semblent bien supportés par pas mal d'OS, même si c'est peu pratique à la ligne de commande. Ce n'est pas uni limitation en soi...
 
Quant au support UTF-8, il n'est pas présent dans tous les OS et FS. Avec windows 98 sur un Samba 2 qui stocke ses fichiers dans un ext2 NLS ascii, ça risque d'être problématique...

Obiwan n'a pas de limite dans ses noms de fichiers

moi j'ai des pb de compatibilité entre nux et osx :
les espaces et accentuations ne sont pas les bienvenues  
je suis toujours obliger de renommer "proprement" (tirets ou underscrore) avant l'ouverture d'un fichier  
 
sinon qd je créé des fichiers pour les serveurs http ou pour moi même d'ailleurs, j'évite de trop de longueur (<32char).
je préfère eventuellement mettre des versions ou créer une arbo datée pour m'y retrouver plutôt que mettre par exemple :
unfile que j'ai créé en oct 2007.zip
 
je garde qd même les habitudes extensions pour avoir une idée de son contenu sans être obliger de l'ouvrir.

Euh sauf erreur mais linux les seules limitations sont :
- pas de /
- pas de '\0'

après tu peux nommer comme tu veux. Bref faut pas confondre avec les limitations de certains systèmes de fichiers designés par les mêmes gars qui pensaient qu'on tiendrait un siècle avec 640K

+1 pour taz

De même.
 
Avec les systèmes de fichiers UNIX modernes (ext, ReiserFS, XFS, JFS, ZFS, etc.) dans l'absolu je crois qu'on ne puisse plus vraiment parler de limitation dans les noms de fichiers (aussi bien du point de vue des types de caractères supportés que du point de vue de la longueur des chaînes de caractères).
 
Après, plus concrètement, si limitation il doit y avoir, c'est surtout lorsqu'on parle en termes d'intéropérabilité avec des FS plus restrictifs ; par exemple en cas de partage de fichiers avec des systèmes et réseaux hétérogènes, ou bien encore lors de l'archivage de données sur certains médias (données au format ISO avec des extensions Joliet sur CD ou DVD, typiquement).
 
D'autres soucis peuvent survenir avec l'encodage (charset) des noms de fichiers comme cela a été remarqué ; mais c'est à mon sens une situation temporaire, de transition, car on se dirige clairement vers du tout UTF-8 à moyen terme.