Discussion :

[Atasuke]

Bonjour,

En partant du principe que les extensions sont facultatives, comment peut on via un programme C identifier la nature d'un fichier. (sur linux)
Par exemple, comment différencier un exécutable d'une vidéo?

Toute aide est la bienvenue, je vous remercie.

Ata

Edit : Bon en faite après réflexion j'ai trouvé x). Il faut passer par une commande système et un fichier intermédiaire. :-)

[Obsidian]

Bonsoir,

En partant du principe que les extensions sont facultatives, comment peut on via un programme C identifier la nature d'un fichier. (sur linux)
Par exemple, comment différencier un exécutable d'une vidéo?

Il n'y a pas de manière déterministe pour faire cela. La « nature » d'un fichier ne dépend que de son contenu, lequel est totalement indépendant du système d'exploitation lui-même, pour qui une vidéo et un fichier exécutable sont tous deux des fichiers ordinaires.

Sous UNIX en particulier, on distinguera malgré tout les quelques cas qui se distinguent des fichiers ordinaires sur un système de fichiers, et qui sont gérés directement par le noyau du système : les répertoires (« d »), les sockets (« s »), les tubes nommés (« p »), les fichiers spéciaux (« b » ou « c »), les liens symboliques (« l ») et éventuellement les doors Solaris (« D »).

Edit : Bon en faite après réflexion j'ai trouvé x). Il faut passer par une commande système et un fichier intermédiaire. :-)

Si par une commande système et un fichier intermédiaire, tu entends « system("file nomdufichier"); », alors tu n'es pas tout-à-fait dans le vrai. « system » est une commande qui appelle le shell par défaut depuis un programme en cours d'exécution et lui passe une commande comme si c'était l'utilisateur qui l'avait lancée.

Ceci aura pour effet d'exécuter le programme nommé « file » qui sert justement à identifier le contenu d'un fichier si c'est possible. Pour ce faire, il s'y prend en s'aidant d'une base de connaissance et d'une batterie de tests. Néanmoins, il est tout-à-fait possible qu'il ne reconnaisse pas ce contenu.

En revanche, les systèmes d'exploitation proposent souvent des mécanismes permettant aux différents logiciels de « s'enregistrer », d'une part, et de fournir leurs propres ressources pour identifier ces fichiers.

Sous Unix, enfin, tout programme interprété commençant par « #!chemind'access » sera automatiquement exécuté par le système, qui lancera le programme indiqué par chemind'acces en lui passant en argument le nom du fichier concerné. Par exemple, si l'utilisateur essaie de lancer un fichier dont le contenu débute par « #!/bin/perl », alors le système lancera automatiquement la commande « /bin/perl fichier ». La commande « file » et les autres systèmes peuvent s'appuyer dessus pour estimer raisonnablement qu'il s'agisse d'un script Perl.

[Atasuke]

Je te remercie pour avoir pris le temps de me répondre :-)
Je ne pensais pas avoir de réponse aussi complète si rapidement.

Concernant ton explication, je ne te cache pas qu'elle m'a un peu surprise au début.
Je trouve inquiétant que finalement, le système laisse les éditeurs plus ou moins déterminer le type du fichier. Que se passe t-il en cas de conflits, par exemple?

Mais après réflexion, c'est vrai que ça parait logique, sans ça on aurait pas un système aussi évolutif et permissif qu'a l'heure actuelle.

Bonne soirée

Ata

[Pouet_forever]

Les fichiers communément utilisés ont un en-tête bien particulier qui leur est propre. A partir de cet en-tête, tu peux déterminer quel genre de fichier c'est.
Bien sûr, pour pouvoir déterminer ça correctement, il faut connaître les en-tête des fichiers, tout en-tête non connu sera considéré comme tel.

[Obsidian]

Concernant ton explication, je ne te cache pas qu'elle m'a un peu surprise au début. Je trouve inquiétant que finalement, le système laisse les éditeurs plus ou moins déterminer le type du fichier. Que se passe t-il en cas de conflits, par exemple?

Ça, ça a toujours été une crainte. Les risques de collision ne sont jamais nuls, même s'ils sont faibles. Et c'était d'autant plus vrai lorsque l'on utilisait le format 8.3 du D.O.S. Seuls les trois caractères de l'extension du nom de fichier faisaient foi car alors, ouvrir un fichier était très coûteux, surtout lorsque l'on travaillait sur disquette.

Cela dit, globalement, cela n'a jamais posé de réel problème, mais c'est aussi dû au fait que l'utilisation de l'informatique par le grand public était nettement moins répandue, quoi que conséquente tout de même, et qu'Internet n'était pas dans les foyers (on s'échangeait des documents par disquette interposée, ce qui limitait beaucoup le débit et le volume des données échangées). Il en reste qu'il fallait faire attention : la plupart du temps, cela ne posait pas de problème, mais quand Microsoft s'est mis à sortir des documents Word estampillés « *.doc », par exemple, ça a fait suer tout le monde. D'abord, parce que ce n'était pas du tout descriptif (un « document », cela peut être n'importe quoi), ensuite parce que cette extension était déjà largement répandue « de fait » pour contenir la documentation du logiciel qu'elle accompagnait. Un tel fichier était complètement informel mais son contenu allait du simple ReadMe à la man page, et parfois jusqu'à un manuel complet et détaillé. Autre signe particulier : ce fichier était forcément écrit en mode texte et lisible avec n'importe quel éditeur.

C'était aussi le cas avec les cartes d'extensions électroniques que l'on fourre dans son ordinateur : celles-ci doivent en principe avoir une position fixe sur le plan mémoire pour pouvoir communiquer avec le C.P.U. Le constructeur se réservait généralement le droit de réserver lui-même les plages occupées et quiconque souhaitait développer un produit compatible devait se rapprocher dudit constructeur (et lui payer une somme substantielle). Le bus P.C.I. a en partie pallié ces difficultés.

Comme le dit Pouet_forever, n'importe qui peut créer un nouveau format de fichier comme ça lui chante et y mettre ce qu'il a envie, et c'est pour cela que la plupart des développeurs y insèrent un signe distinctif propre et souvent calculé à partir du reste des données, pour diminuer encore plus le risque de collision. Lorsque ce format est établi comme tel à la base et que la norme est rendue publique, les choses sont simples. C'est pour les autres fichiers que c'est plus difficile.

Tu peux enfin utiliser n'importe quelle méthode pour distinguer de façon certaine un fichier ou une ressource quelconque, mais il existe aujourd'hui les UUID : http://fr.wikipedia.org/wiki/Univers...que_Identifier

Un UUID est un numéro généré à partir de l'heure courante et des identifiants d'une machine, ce qui le rend virtuellement unique, car la probabilité que deux ordinateurs sur la planète arrivent effectivement à générer le même identifiants indépendamment l'un de l'autre est extrêmement faible. Les UUID ont l'avantage d'être normalisés tout en restant relativement simple à produire. Tout le monde peut donc les reconnaître et les lire, et tout le monde peut en produire autant qu'il souhaite.

Si tu veux produire des fichiers qui seront reconnus à coup sûr comme respectant un format que tu as défini, il te suffit de produire un UUID une fois pour toutes, puis de publier dans une norme à toi un format d'entête de fichier incluant cet UUID (toujours le même), et une somme de contrôle ou un CRC de cette entête avec un diviseur fixe, lui-aussi. À ce stade, tu pourras garantir presqu'à 100% qu'un tel fichier est un fichier respectant ton format.

À dire vrai, si les données qui suivent ne correspondent pas, il faudra plutôt considérer ton fichier comme étant corrompu (par exemple, à la suite d'un transfert qui se serait mal déroulée) plutôt que comme une collision.

[Atasuke]

Merci pour les explications :-).