Biensûr je sais ce qu'est un Fichier, mais en dehor de l'image qu'on à tous d'un fichier, qu'est-ce que c'est ? Un tableau extensible ? Imaginons que les fichiers n'existent pas et que je voudrais les codés, que doit je écrire ? Et peut on voir le code source d'un Fichier ?
C'est une question qui m'est venu soudainement aujourd'hui ...
Une suite d'octets étant référencé dans un bloc mémoire de l'unité de stockage réservée à cet effet selon un systeme de fichier?
Tu peux voir le contenu d'un fichier avec un éditeur hexadécimal... pour certains fichiers tu verras leur contenu en clair (fichier txt, image bmp), d'autres sont compressés selon un algorithme de compression (jpg, tiff) et d'autre selon un algo propriétaire...
"Une suite d'octets étant référencé dans un bloc mémoire de l'unité de stockage réservée à cet effet selon un systeme de fichier?"
Un fichier c'est une suite d'octets ? Oui mais comme n'importe qu'elle programme ... ça ne répond pas à la question.
Non je ne veux pas voir le contenu d'un fichier, mais le code source du fichier comme le code source de n'importe qu'elle autre programme... A moins qu'un fichier ne soit pas un programme ... J'ai du mal à concevoir ce qu'est un fichier :/
C'est bien une suite d'octet, comme les programmes d'ailleur, mais il n'a pas de code source.
Un programme est une suite d'octets qui forment une suite d'instructions destinées à être exécutés par l'OS (un OS qui reconnait ces instructions).
Un fichier est une suite d'octets qui forment plusieurs informations destinées à être lues par le programme (programme qui reconnait la structure de ces infos) qui à besoin de ce fichier et interprète ces informations pour t'afficher un résultat.
Ex : un fichier txt est lu par un éditeur (qui connait la structure du fichier txt) qui t'affiche le contenu du fichier.
C'est difficile de faire plus simple :s
EDIT : PS : Et fait quand même attention à une chose : un programme ne contient pas un code source, il contient le résultat de la compilation d'un code source. Un fichier .c, .cpp, ou autre n'est qu'un vulgaire fichier txt avec une autre extension et donc incompréhensible par l'OS, et donc l'ordinateur lui même!
- Edité par stephan1932 17 février 2013 à 18:36:29
Euh... Un programme peut-être un fichier ^^" Par exemple, firefox est un programme dont le fichier principal est firefox.exe sous Windows ...
Les infos de stephan1932 me semble on ne peut plus exactes Un fichier est définie par un système de fichier ... Mais au final, l'utilisateur lui ne verras qu'une suite d'octet qui à plus ou moins de sens ...
Par exemple un fichier .txt est une suite d'octet qui ne contient que des caractères imprimable ... Un fichier BMP (Image bitmap) est une suite d'octet qui commence par 'BM'. Alors q'un programme serra une suite d'octet que Windows ( Ou Mac ) pourra interprété et exécute comme un programme ...
- Edité par @che 17 février 2013 à 18:43:16
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles- ♡ Copying is an act of love.
La définition d'un fichier a globalement été défini ici mais nous pouvons allouer plus loin.
Un fichier est une abstraction logique pour lu système d'exploitation et l'utilisateur. Via un système de fichiers, il y a correspondance entre le fichier logique (exemple : /home/Renault/essai.txt) et sa réalité physique à savoir des secteurs d'un disque dur ou des cellules mémoires en SSD par exemple.
Ce qui va faire la différence entre un fichier de données et un programme c'est en effet son format. Dans certains systèmes, tout est fichier ! Même les programmes. Le programme en est effet lui aussi une suite d'octets mais dans un format particulier qui a été généré à partir de la compilation et l'édition des liens du code source. Par exemple de nombreux UNIX comme Linux utilisent le format EFL pour représenter les programmes et les exécuter. Windows et Mac OS X en utilisent d'autres (c'est l'une des explications sur l'impossibilité d'utiliser des programmes Windows sous Linux et inversement, mais pas que).
Un fichier de données quant à lui à un format différent et identifié comme non exécutable par les systèmes d'exploitation. Chaque fichier a une en-tête que chaque programme va tenter d'interpréter et s'il correspond à un format connu par le programme, il va pouvoir le manipuler et le représenter à l'utilisateur.
Du coup au final, quel que soit le fichier, tu as la même chose (des octets sur un support physique), seul le format va donner à un sens à ces octets pour être manipuler comme un programme ou comme des données.
Par exemple un fichier .txt est une suite d'octet qui ne contient que des caractères imprimable ... Un fichier BMP (Image bitmap) est une suite d'octet qui commence par 'BM'. Alors q'un programme serra une suite d'octet que Windows ( Ou Mac ) pourra interprété et exécute comme un programme ...
Je te fous une image Bitmap dans un .txt quand tu veux, et inversement. La notion de type de fichier n'est absolument pas liée à son extension. Faudra arrêter avec ça un jour.
Koinko.in, le raccourcisseur d'URL qu'il est bien - Zingwai vaincra.
Par exemple un fichier .txt est une suite d'octet qui ne contient que des caractères imprimable ... Un fichier BMP (Image bitmap) est une suite d'octet qui commence par 'BM'. Alors q'un programme serra une suite d'octet que Windows ( Ou Mac ) pourra interprété et exécute comme un programme ...
Je te fous une image Bitmap dans un .txt quand tu veux, et inversement. La notion de type de fichier n'est absolument pas liée à son extension. Faudra arrêter avec ça un jour.
Il a raison, l'en-tête du fichier BMP débute par BM pour cette raison, c'est un des éléments qui permettent son identification.
Seulement le reste de l'en-tête est aussi un indicateur, s'il n'arrive pas à le parser correctement (car des éléments divergent comme sur la taille du fichier), alors le programme abandonnera la tentative de lecture. Il ne suffit pas d'un 'BM' pour que le reste soit correct, le reste de l'en-tête est bien plus complet et fiable.
Rigolo que personne ne parle d'inode, la base des systèmes de fichier sous Linux.
En fait, ce n'est pas spécifique à Linux : un système de fichiers est généralement un arbre (plus ou moins : les hardlinks cassent la structure en arbre), avec des noeuds. Pour peu que tu donne un index aux noeuds, ce qui est quand même vachement pratique pour les référencer, tu as des inodes. Maintenant, comme l'a signalé LoupSolitaire, c'est plus la tambouille interne du filesystem qu'un attribut du fichier.
Soit, mais on peut considérer que ça gère les meta-données qui décrivent un fichier au delà des données du fichier en lui-même (droit d'accès, taille, ...). Quand tu cliques droit sur un fichier pour voir ses propriétés, c'est cet inode qui est récupéré/traité. Le fichier en lui-même, après tout, ce n'est qu'une liste chainée de blocs mémoire contenant les octets.
Oui mais après comme nous l'avons dit, tu tombes sur des détails de choix d'implémentation de différents systèmes de gestion des fichiers.
Ici la question était large et plutôt générique, l'abstraction du fichier a été bien expliqué ici.
D'autant qu'en soit, les méta-données du système de gestion du fichier (qui ne sont pas ceux de son en-tête), n'aident pas du tout à répondre à sa problématique initiale...
Je cite une phrase tirée de la problématique initiale: "Imaginons que les fichiers n'existent pas et que je voudrais les codés, que doit je écrire".
Pour moi, créer un système de gestion de fichiers revient à designer un fichier au travers un objet du type :
{inode,date,access,etc,data:{}} avec data le contenu du fichier en lui-même, le reste gérant les méta données. Voilà comment on pourrait coder un fichier. Je vois pas en quoi c'est HS. En parlant simplement du contenu d'un fichier, comment expliquer la localisation ? La copie d'un fichier ? Tout passe par l'inode.
En bref, un fichier c'est pas simplement les données qu'il contient, mais également les données qui permettent de le définir (de manière unique), appelées meta données.
Après, je n'ai nullement expliqué comment étaient traitées ces méta données par le système de gestion du fichier, comme vous avez l'air de le dire.
Le fichier en lui-même, après tout, ce n'est qu'une liste chainée de blocs mémoire contenant les octets.
Le fichier, c'est un ensemble ordonné de données. C'est le filesystem qui mémorise les données et leur ordre en les stockant dans des blocs de mémoire. D'ailleurs, dans les 3 filesystems que j'ai étudiés, un seul plaçait les blocs de données dans des listes chainées (un filesystem en RAM).
Ce qu'il faut comprendre, c'est que le fichier, c'est quelque chose d'abstrait, et qu'on ne code pas un fichier, mais un outils de gestion de fichiers, qu'on appelle système de fichiers. Toutes les méta données (droits d'accès &co) ne font ps parties du fichier. Ce sont des données supplémentaires gérées par le système de fichiers.
Le fichier en lui-même, après tout, ce n'est qu'une liste chainée de blocs mémoire contenant les octets.
Le fichier, c'est un ensemble ordonné de données. C'est le filesystem qui mémorise les données et leur ordre en les stockant dans des blocs de mémoire. D'ailleurs, dans les 3 filesystems que j'ai étudiés, un seul plaçait les blocs de données dans des listes chainées (un filesystem en RAM).
Ce qu'il faut comprendre, c'est que le fichier, c'est quelque chose d'abstrait, et qu'on ne code pas un fichier, mais un outils de gestion de fichiers, qu'on appelle système de fichiers. Toutes les méta données (droits d'accès &co) ne font ps parties du fichier. Ce sont des données supplémentaires gérées par le système de fichiers.
Ha d'accord ... Mais le système de fichier est contenu dans l'OS ? Et le code source de l'OS est bien contenu dans des fichiers non ?
Ne mélange pas tout.
Oui le système de fichier est contenu dans le système d'exploitation. Cependant pour lancer un système d'exploitation, il n'y a pas besoin de son code source mais uniquement le fichier binaire résultant de la compilation et de l'édition des liens de ce code. Du coup tu vas te retrouver avec un fichier binaire pour le système.
Seulement, cela n'est pas tout, pour charger le système il suffit de chercher un code présent sur un secteur particulier du disque dur en faisant totalement abstraction du système de fichier et du concept de fichier car on charge directement les secteurs ! Une fois chargée, le système de fichier rependra rapidement le relais pour utiliser ce concept.
Un fichier n'a aucune existence physique, c'est un concept purement logiciel pour se simplifier la vie.
edit : bon ben je dis comme Renault, mais formulé autrement. Bon, du coup je laisse. Mais c'était quand même super pratique l'indication "quelqu'un a posté avant vous"
Est ce que le système de fichier est dans l'OS ? Pas forcément, néanmoins, tu as mis le doigt sur un point intéressant, le système de fichiers, c'est du code compilé, enregistré dans des fichiers, l'OS, qui ordonne le tout, c'est aussi du code compilé enregistré dans des fichiers. Donc comment on fait pour démarrer le système ? En fait, ton processeur est fait pour démarrer en exécutant un programme qui n'est pas stocké dans un fichier, en sachant simplement où aller le chercher dans une mémoire (qui est souvent dans le processeur). Ce programme peut contenir ton système de fichier pour accèder au disque dur, charger l'OS, le filesystem, etc...
Bon, dans les faits, il y a plus d'étapes que ça : sur PC, je crois qu'on a dans l'ordre le chargement du bios, qui vient charger le loader (Windows loader, grub, lilo, ...) qui vient charger l'OS. Chaque étape intermédiaire a son utilité, que je ne détaillerai pas ici. Il faut juste comprendre que les programmes des premières étapes ne sont pas dans des fichiers, et qu'ils contiennent le code pour retrouver les fichiers dans la mémoire.
- Edité par Natalya 20 février 2013 à 13:51:49
64kB de mémoire, c'est tout ce dont j'ai besoin
C'est quoi un fichier ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
Blond, bouclé, toujours le sourire aux lèvres...