est-il possible de paramétrer Linux pour qu'il ne soit plus case sensitive ?
si oui, quel est ce paramètre ?
 
 
PS : je ne connais rien à Linux, c'est juste pour information

 
ben contrairement a windows (vfat en fait), fichier et FiChIeR sont pas les memes fichiers, dc c forcement case sensitiv...
 

je sais, mais est-il possible de le paramétrer qlq part ?

 
c le format des partition ki te le permet pas, c pas juste un parametre (sauf erreur de ma part)

utilise l'auto completion, ça évite un paquet d'erreur dù à ça (tu tapes le début de la commande et tu fais TAB, et là, il finit la commande où il te propose la liste si il y a plusieurs possibilités)

sinon, informatiquement parlant, a est different de A donc le case sensitive est tout a fait logique
 
c'est dos/windows qui ne l'est pas...

 
me semble meme ke sauf contreindication sur les dernieres version, windows stockai tout en majuscule et faisait une presentation standardiser sauf si on tapai un nom avec une casse a la con

 
possible, ils sont capables de tout

 
Les noms longs, c'est pire que ça. La FAT (même FAT32) est toujours 8+3 pour les noms de fichiers.
 
En fait, quand tu as un fichier "coincoinpanpan.txt" (14+3), le nom est découpé.
Il y a un fichier coinco~1.txt qui contient les données, fichier normal.
Mais il y a deux autres fichiers créés :  
 
    inpanp~1
    an~1
 
Qui sont invisible car positionnés avec une combinaison d'attribut spéciale (qui était théoriquement impossible à l'origine, c'est pour cela qu'elle s'est retrouvé là et qu'on ne peut pas les voir).
 
Cette organisation tordu deux se voir à l'éditeur hexa (toi aussi, va editer /dev/hda1), ou dans des cas tordu (RAMDISK avec un nombre de fichiers limitées dans la racine, tu crois créer un fichier, tu en a trois ).
 

Ben vi c'est possible, tu recodes le kernel, tu compiles, et pis voila...
(t'as demandé possible, pas facile... tout est possible !!!)

NTFS est sensible à la casse (minuscules et majuscules sont différenciés) mais pour ne pas perturber les utilisateurs, il n'est pas permis d'avoir 2 fichiers de même nom et de casse différente (CoinCoin.txt ne peux pas co-exister avec COINCOIN.txt). Bref ça laisse rêveur...

je sais pas si reveur est le mot le plus adapté la...
ca laisse plutot   ou bien encore et meme    
Mais reveur, pas du tout...

 
en fait, j'ai une application qui a été développée en PHP4/MySQL sous Windows. Elle fonctionne parfaitement
le portage sous Unix montre que le codage n'a pas été rigoureux au niveau de la casse
deux possibilités donc :  
soit réécrire le code pour tous passer en Min ou en Maj
soit paraméter Linux pour supprimer le case sensitive
 
à priori, seule la première solution est possible

bardass a écrit a écrit :     en fait, j'ai une application qui a été développée en PHP4/MySQL sous Windows. Elle fonctionne parfaitement le portage sous Unix montre que le codage n'a pas été rigoureux au niveau de la casse deux possibilités donc :   soit réécrire le code pour tous passer en Min ou en Maj soit paraméter Linux pour supprimer le case sensitive   à priori, seule la première solution est possible

 
en meme tps c un peu con de faire un text avec une casse zarb...
 
si tu veux un truc: tu dev rapidemetn (php/perl ou ce ke tu manie le mieux, meme c c court) une appli ki converti brut de pomme tt en minuscule ss reflechir, et pareil pour les tables, les fichiers kils utilisent... tu aura pu de prob... et ca sera reportable sous win en pluche

on a pas choisi la casse, on a récupéré un dév en l'état
 
effectivement, il faut qu'on se tape un script qui scrute toutes les sources pour basculer les majuscules en miniscules
mais vu le nombre de lignes et le nombre de fichiers, on aurait préféré faire autrement (du style, paramétrer la casse sous Linux)
 
mais vu que ça a l'air impossible ...

g pas di ki scrute... g dis ki met la casse en minuscule de force meme si elle y est deja, g vachement moins compliké

je vois pas le pb.
si c'est un script qui le fait, peut importe les nombres de fichiers et de lignes.

En plus, même si on peut s'arranger pour que le système de fichiers ne soit plus sensible à la casse, il ne sera plus trop POSIX. On s'en fout, mais quand même.
Sinon, le script qui passe tout en minuscules, je veux bien, mais si sous Unix, une fonction d'une bibliothèque quelconque est écrite ReadMachin(), et que le code y fait appel, si il est transformé en readmachin(), est-ce que ça ne va pas poser de problèem (on suppose évidemment que le code de la bibliothèque ne peut pas êter changé).

Ben, je me souviens, sous Windows 95 (et 98 aussi, il me semble), que si on tapait un nom en 8+3 en majuscules, alors, il l'écrivait avec une majuscule au début et ensuite des minuscules. Pas trop gênant, mais assez bizarre, surtout quand tu ne retrouves pas le nom que tu viens d'écrire en majuscules, en gros, pour ne pas le perdre

Jak a écrit a écrit : Ben, je me souviens, sous Windows 95 (et 98 aussi, il me semble), que si on tapait un nom en 8+3 en majuscules, alors, il l'écrivait avec une majuscule au début et ensuite des minuscules. Pas trop gênant, mais assez bizarre, surtout quand tu ne retrouves pas le nom que tu viens d'écrire en majuscules, en gros, pour ne pas le perdre

 
Vrai. J'ai encore ma partition 98 et c'est comme ça. Ca masque meme les extensions par defaut, t'imagines le bordel : quand tu veux changer une extension, si tu rajoutes l'extension à la main, tu obtiens un fichier fichier.nouvelle_extension.ancienne_extension. Donc ça change rien
Y a moyen de changer tout ça dans les préférences d'explorer, mais c'est chiant.

(mode culture generale on)
 
@Kadreg : en fait c'est un poil plus compliqué que cela.
 
Historiquement, quand DOS effaçait un fichier, il remplaçait dans la fat le premier caractere du nom de fichier par un caractere "sigma" (j'me souviens plus de la valeur ASCII...) pour signifier que ce fichier etait effacé. Les valeur des zones du disque ou ce fichier etait stocké n'etaient pas effacées, et c'est sur ce principe que des utilitaires comme "undelete" fonctionnaient : on demande a l'utilisateur le premier caractere du fichier, on tente de recuperer les valeurs et on voit si ca marche ou pas. Si les donnees ont ete ecrasee ca vautre sinon c'est bon on a recuperé le fichier
 
Quand ils ont créé le systeme de noms longs pour Win95, ils ont détourné cette astuce de la façon suivante.
Un fichier est TOUJOURS stocké en 8.3 avec l'algo suivant :
- on garde les 6 premiers caracteres alphanumeriques du nom situés avant le premier '.' suivis de "~1" puis des 3 premiers caracteres alphanumeriques qui suivent le dernier '.' le tout converti en majuscules (toujours)
- si ce nom existe deja, on remplace le "~1" par "~2" et on essaie à nouveau
- au cas où, on va jusqu'a "~4"
- si ca marche toujours pas, on attribue les 6 premiers caracteres AU HASARD suivi de "~1", jusqu'a ce qu'on trouve un nom de fichier non utilisé dans le repertoire en cours. Comme le nombre maxi de fichiers d'un repertoire windows est inferieur aux nombre de combinaisons differentes de 6 caracteres alphanumeriques, on est assuré de pouvoir obtenir ce nom (sinon c'est une erreur de type "trop de fichiers" qui a du etre levée au moment de la tentative de creation)
 
- une fois le nom 8.3 ecrit, on va ajouter une entrée dans la FAT qui va contenir le nom long de la façon suivante :
"sigma"+les 62 premiers caracteres du nom+"1" pour arriver à 64 caractere, taille maxi d'une entree dans la FAT
- si le nom fait plus de 62, on ajoute JUSTE DERRIERE "sigma"+les 62 caracteres qui suivent+"2"
- etc... jusqu'a 255, taille maxi d'un nom de fichier long.
 
Les entrées commençant par "sigma" ne sont jamais affichées lors d'un parcours de repertoire pour les raisons historiques que j'ai données au début, donc la bidouille reste pseudo-invisible.
Les entrées "nom long" dans la FAT sont toujours immédiatement consecutives à l'entrée 8.3 (quand pour une raison X ou Y elles en sont séparées, seul le 8.3 est affiché, et les entrées longues deviennent invalides... Il y avait des utilitaires comme LFNBACKUP pour corriger ce genre de soucis )
 
Ca peut se voir en utilisant des vieux utilitaires disques qui datent du DOS : ils petent completement les plombs avec les noms longs
 
PS : les tailles max etc.. sont faites de memoire, peut etre qu'en FAT32 elles sont legerment differentes, mais c'est le principe de fonctionnement de la FAT
 
(mode culture generale fini )

Punaise, mais c'est l'enfer.
Sinon, comme quelqu'un le disait plus haut, je trouve que la sensibilité à la casse de la NTFS est un peu bizarre.

zeb2 a écrit a écrit :     Vrai. J'ai encore ma partition 98 et c'est comme ça. Ca masque meme les extensions par defaut, t'imagines le bordel : quand tu veux changer une extension, si tu rajoutes l'extension à la main, tu obtiens un fichier fichier.nouvelle_extension.ancienne_extension. Donc ça change rien Y a moyen de changer tout ça dans les préférences d'explorer, mais c'est chiant.

En fait, ça, ça le fait même encore maintenant dans Windows XP, et ça peut aussi se faire sous KDE et Gnome.
Le problème, c'est que c'est le mode par défaut, et c'est sujet à confusion (ben oui, on ne voit pas que le fichier attaché s'appelle en fait TOTO.JPG.exe, car les gens finalement ne font pas attention si ils voient TOTO.JPG, même si l'affichage qu'il devrait y avoir TOTO).
L'extension devrait TOUJOURS être affichée, je trouve.