A voir également:
- C'est quoi un fichier?
- Fichier rar - Guide
- Fichier host - Guide
- Fichier iso - Guide
- Comment réduire la taille d'un fichier - Guide
- Comment ouvrir un fichier epub ? - Guide
62 réponses
1. est-ce un emplacement contigu de bits, d'octets, de 32 bits?
=> non. Un fichier est composé d'un ou plusieurs blocs de données sur support magnétique ou mémoire flash
2. Le fichier peut-il ne pas être contigu?
=> oui. imagine une bibliothèque où les livres ne sont pas tassés d'un côté ou de l'autre. Si je stocke une encyclopédie en 20 volumes, au lieu de chercher un espace contigu où la stocker je préfère stocker le 1er volume dans le 1er espace disponible, le 2nd volume dans le 1er espace nouvellement disponible etc
3. Si non, comment le lancer en mémoire vive, s'il fait plusieurs Mo? (il n'y a peut être pas autant de bits juxtaposés).
=> on ne charge plus l'intégralité d'un fichier depuis belle lurette, un fichier est lu bloc par bloc. Certaines optimisations peuvent t'amener à charger un fichier intégralement en mémoire, mais ça n'est qu'une optimisation, pas la règle.
4. Et d'ailleurs, comment lancer des fichiers de plusieurs Go ?
=> les fichiers ne sont pas lancés. Les programmes oui. Mais quand on démarre un programme, le système ne charge pas en mémoire l'intégralité du fichier contenant le programme
5. Est-ce que l'extension a une importance dans la mémoire ?
=> aucune
6. Si c'est un fichier texte, on peut accéder au second caractère en lisant le 2eme octet?
=> c'est dans les fichiers séquentiels où pour accéder au nième caractère, il faut lire les n-1 caractères qui le précèdent
7. Ces réponses sont-elles valables indépendamment de l'OS ?
=> oui. Excepté que tu peux tomber un jour sur un OS exotique (ou dépassé) où l'un de ces constats n'est pas vrai. exemple: le BDOS qui équipait les premiers micro-ordinateurs de l'éducation nationale française ne pouvait pas laisser des espaces vides entre les fichiers. du coup, les fichiers étaient forcément contigus. Mais c'était extrêmement couteux en temps
8. Mêmes questions pour les dossiers.
=> le dossier ne sert qu'au classement des fichiers, à leur organisation d'une manière plus ou moins logique
=> non. Un fichier est composé d'un ou plusieurs blocs de données sur support magnétique ou mémoire flash
2. Le fichier peut-il ne pas être contigu?
=> oui. imagine une bibliothèque où les livres ne sont pas tassés d'un côté ou de l'autre. Si je stocke une encyclopédie en 20 volumes, au lieu de chercher un espace contigu où la stocker je préfère stocker le 1er volume dans le 1er espace disponible, le 2nd volume dans le 1er espace nouvellement disponible etc
3. Si non, comment le lancer en mémoire vive, s'il fait plusieurs Mo? (il n'y a peut être pas autant de bits juxtaposés).
=> on ne charge plus l'intégralité d'un fichier depuis belle lurette, un fichier est lu bloc par bloc. Certaines optimisations peuvent t'amener à charger un fichier intégralement en mémoire, mais ça n'est qu'une optimisation, pas la règle.
4. Et d'ailleurs, comment lancer des fichiers de plusieurs Go ?
=> les fichiers ne sont pas lancés. Les programmes oui. Mais quand on démarre un programme, le système ne charge pas en mémoire l'intégralité du fichier contenant le programme
5. Est-ce que l'extension a une importance dans la mémoire ?
=> aucune
6. Si c'est un fichier texte, on peut accéder au second caractère en lisant le 2eme octet?
=> c'est dans les fichiers séquentiels où pour accéder au nième caractère, il faut lire les n-1 caractères qui le précèdent
7. Ces réponses sont-elles valables indépendamment de l'OS ?
=> oui. Excepté que tu peux tomber un jour sur un OS exotique (ou dépassé) où l'un de ces constats n'est pas vrai. exemple: le BDOS qui équipait les premiers micro-ordinateurs de l'éducation nationale française ne pouvait pas laisser des espaces vides entre les fichiers. du coup, les fichiers étaient forcément contigus. Mais c'était extrêmement couteux en temps
8. Mêmes questions pour les dossiers.
=> le dossier ne sert qu'au classement des fichiers, à leur organisation d'une manière plus ou moins logique
Utilisateur anonyme
27 nov. 2009 à 18:06
27 nov. 2009 à 18:06
Bonjour a étudier.
https://www.commentcamarche.net/faq/s/fichiers
https://www.commentcamarche.net/faq/s/fichiers
Bonjour,
j'avais déjà cherché un peu sur wikipedia et sur commentcamarche, sans trouver de reponse vraiment satisfaisante, et c'est pourquoi j'ai posté un sujet ici.
Pouvez-vous répondre à mes questions s'il vous plait?
Merci d'avance pour votre aide.
j'avais déjà cherché un peu sur wikipedia et sur commentcamarche, sans trouver de reponse vraiment satisfaisante, et c'est pourquoi j'ai posté un sujet ici.
Pouvez-vous répondre à mes questions s'il vous plait?
Merci d'avance pour votre aide.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
kilian
Messages postés
8731
Date d'inscription
vendredi 19 septembre 2003
Statut
Modérateur
Dernière intervention
20 août 2016
1 527
27 nov. 2009 à 18:52
27 nov. 2009 à 18:52
Salut,
je débute en c et pour mieux le comprendre j'aimerais savoir ce qu'est un fichier, au niveau de la mémoire :
1. est-ce un emplacement contigu de bits, d'octets, de 32 bits?
Oui, c'est un emplacement d'octets contigus.
En réalité ça ne l'est pas. Un fichier est organisé de manière différente sur un support de stockage selon le système de fichier que tu utilises (NTFS/Fat, etc..). Et donc il peut être fragmenté. Mais en fait tu n'as pas à t'en soucier car c'est le système d'exploitation qui gère ça, il se charge de l'abstraction de tes fichiers qui contiennent de ton support de stockage et t'en fourni une représentation d'octets contigus.
2. Le fichier peut-il ne pas être contigu?
Non, son contenu est toujours linéaire et ordonné.
3. Si non, comment le lancer en mémoire vive, s'il fait plusieurs Mo? (il n'y a peut être pas autant de bits juxtaposés).
Pas de problèmes, la taille du fichier ne change rien.
4. Et d'ailleurs, comment lancer des fichiers de plusieurs Go ?
Tu entends quoi par "lancer"?
5. Est-ce que l'extension a une importance dans la mémoire ?
Non. Ton système d'expoitation peut interpréter l'extension du fichier et donc determiner quel programme
utilisé pour l'ouvrir, mais en dehors de ça ça ne change rien à son contenu.
6. Si c'est un fichier texte, on peut accéder au second caractère en lisant le 2eme octet?
Oui.
7. Ces réponses sont-elles valables indépendamment de l'OS ?
Oui.
8. Mêmes questions pour les dossiers.
Euh, difficile à comprendre cette question... :)
je débute en c et pour mieux le comprendre j'aimerais savoir ce qu'est un fichier, au niveau de la mémoire :
1. est-ce un emplacement contigu de bits, d'octets, de 32 bits?
Oui, c'est un emplacement d'octets contigus.
En réalité ça ne l'est pas. Un fichier est organisé de manière différente sur un support de stockage selon le système de fichier que tu utilises (NTFS/Fat, etc..). Et donc il peut être fragmenté. Mais en fait tu n'as pas à t'en soucier car c'est le système d'exploitation qui gère ça, il se charge de l'abstraction de tes fichiers qui contiennent de ton support de stockage et t'en fourni une représentation d'octets contigus.
2. Le fichier peut-il ne pas être contigu?
Non, son contenu est toujours linéaire et ordonné.
3. Si non, comment le lancer en mémoire vive, s'il fait plusieurs Mo? (il n'y a peut être pas autant de bits juxtaposés).
Pas de problèmes, la taille du fichier ne change rien.
4. Et d'ailleurs, comment lancer des fichiers de plusieurs Go ?
Tu entends quoi par "lancer"?
5. Est-ce que l'extension a une importance dans la mémoire ?
Non. Ton système d'expoitation peut interpréter l'extension du fichier et donc determiner quel programme
utilisé pour l'ouvrir, mais en dehors de ça ça ne change rien à son contenu.
6. Si c'est un fichier texte, on peut accéder au second caractère en lisant le 2eme octet?
Oui.
7. Ces réponses sont-elles valables indépendamment de l'OS ?
Oui.
8. Mêmes questions pour les dossiers.
Euh, difficile à comprendre cette question... :)
D'accord, merci pour vos réponses.
(notez que parfois vos réponses divergent, mettez-vous d'accord, tapez-vous dessus si besoin :p).
Kilian, excuse-moi pour mon vocabulaire informatique approximatif. Par lancer, comme l'a compris DuCrétin, je veux dire le lire dans la memoire de stockage de masse et le mettre dans la memoire vive, afin qu'il puisse etre lu et modifié.
9. Si un fichier est modifié (et que sa taille augmente) alors qu'il n'y a plus assez de place à coté, comment cela se passe-t-il ? (pour linux, le fichier est-il automatiquement supprimé de son emplacement d'origine et replacé ailleurs, où il y a assez de place ? On m'a dit que Linux ne défragmentait pas les fichiers...)
10. Comment savoir quand on a atteint la fin d'un fichier dans la mémoire? (et quand celui-ci est défragmenté, où est le bout suivant?)
11. Si l'intégrité du fichier n'est pas copiée en mémoire vive à son ouverture, cela veut-il dire que si je descend rapidement vers la fin du document avec mon ascenceur, il faudra attendre que le fichier soit copié en mémoire vive ? (et le début est alors supprimé de la mémoire vive?)
12. Comment un dossier est-il conservé dans la mémoire?
13. J'ai besoin de parser un log en C, et d'y chercher certaines infos. Quels sont les moyens mis à ma disposition? Est-ce que je peux chercher un retour à la ligne (\n), à l'aide d'un fscanf?
(notez que parfois vos réponses divergent, mettez-vous d'accord, tapez-vous dessus si besoin :p).
Kilian, excuse-moi pour mon vocabulaire informatique approximatif. Par lancer, comme l'a compris DuCrétin, je veux dire le lire dans la memoire de stockage de masse et le mettre dans la memoire vive, afin qu'il puisse etre lu et modifié.
9. Si un fichier est modifié (et que sa taille augmente) alors qu'il n'y a plus assez de place à coté, comment cela se passe-t-il ? (pour linux, le fichier est-il automatiquement supprimé de son emplacement d'origine et replacé ailleurs, où il y a assez de place ? On m'a dit que Linux ne défragmentait pas les fichiers...)
10. Comment savoir quand on a atteint la fin d'un fichier dans la mémoire? (et quand celui-ci est défragmenté, où est le bout suivant?)
11. Si l'intégrité du fichier n'est pas copiée en mémoire vive à son ouverture, cela veut-il dire que si je descend rapidement vers la fin du document avec mon ascenceur, il faudra attendre que le fichier soit copié en mémoire vive ? (et le début est alors supprimé de la mémoire vive?)
12. Comment un dossier est-il conservé dans la mémoire?
13. J'ai besoin de parser un log en C, et d'y chercher certaines infos. Quels sont les moyens mis à ma disposition? Est-ce que je peux chercher un retour à la ligne (\n), à l'aide d'un fscanf?
9. Si un fichier est modifié (et que sa taille augmente) alors qu'il n'y a plus assez de place à coté, comment cela se passe-t-il ? (pour linux, le fichier est-il automatiquement supprimé de son emplacement d'origine et replacé ailleurs, où il y a assez de place ? On m'a dit que Linux ne défragmentait pas les fichiers...)
Une erreur est renvoyée au(x) programme(s) qui souhaite(nt) écrire dedans, rien de plus :)
10. Comment savoir quand on a atteint la fin d'un fichier dans la mémoire? (et quand celui-ci est défragmenté, où est le bout suivant?)
Le fichier n'est pas systématiquement chargé en mémoire. Le programme envoie une ou plusieurs demandes de lecture du fichier au système d'exploitation. Lorsqu'il n'y a plus rien à lire, le système d'exploitation renvoie un code particulier (variable selon les systèmes) pour signaler qu'on est arrivé à la fin du fichier.
Lorsqu'un fichier est fragmenté, c'est que sa répartition sur le disque n'est pas contiguë ; s'il est défragmenté c'est qu'il est monobloc, il n'y aurait pas de "bout suivant" . Mais si on atteint la fin d'un fichier, fragmenté ou pas, on est à la fin
11. Si l'intégrité du fichier n'est pas copiée en mémoire vive à son ouverture, cela veut-il dire que si je descend rapidement vers la fin du document avec mon ascenceur, il faudra attendre que le fichier soit copié en mémoire vive ? (et le début est alors supprimé de la mémoire vive?)
bingo!
12. Comment un dossier est-il conservé dans la mémoire?
il n'est pas conservé
13. J'ai besoin de parser un log en C, et d'y chercher certaines infos. Quels sont les moyens mis à ma disposition? Est-ce que je peux chercher un retour à la ligne (\n), à l'aide d'un fscanf?
aucune idée, je ne programme pas en C
Une erreur est renvoyée au(x) programme(s) qui souhaite(nt) écrire dedans, rien de plus :)
10. Comment savoir quand on a atteint la fin d'un fichier dans la mémoire? (et quand celui-ci est défragmenté, où est le bout suivant?)
Le fichier n'est pas systématiquement chargé en mémoire. Le programme envoie une ou plusieurs demandes de lecture du fichier au système d'exploitation. Lorsqu'il n'y a plus rien à lire, le système d'exploitation renvoie un code particulier (variable selon les systèmes) pour signaler qu'on est arrivé à la fin du fichier.
Lorsqu'un fichier est fragmenté, c'est que sa répartition sur le disque n'est pas contiguë ; s'il est défragmenté c'est qu'il est monobloc, il n'y aurait pas de "bout suivant" . Mais si on atteint la fin d'un fichier, fragmenté ou pas, on est à la fin
11. Si l'intégrité du fichier n'est pas copiée en mémoire vive à son ouverture, cela veut-il dire que si je descend rapidement vers la fin du document avec mon ascenceur, il faudra attendre que le fichier soit copié en mémoire vive ? (et le début est alors supprimé de la mémoire vive?)
bingo!
12. Comment un dossier est-il conservé dans la mémoire?
il n'est pas conservé
13. J'ai besoin de parser un log en C, et d'y chercher certaines infos. Quels sont les moyens mis à ma disposition? Est-ce que je peux chercher un retour à la ligne (\n), à l'aide d'un fscanf?
aucune idée, je ne programme pas en C
toto1983
Messages postés
205
Date d'inscription
samedi 16 mai 2009
Statut
Membre
Dernière intervention
25 mars 2010
13
30 nov. 2009 à 13:55
30 nov. 2009 à 13:55
Jennifer, le mieux c que tu te creuse un peu, tiens je te file un tuto concernant es fichiers en langage C
http://www-ipst.u-strasbg.fr/pat/program/tpc05.htm
Là tu as par exemple 2 types de fichiers bruts et bufferisés, dans ce tuto.
Je suis sur qu'il y'en a d'autres.
Je te suggère de tester en utilisant une méthode lseek, et en délimitant par une condition if et stockant dans un tableau les parties pour mieux les traiter.
Tes questions sont pertinentes, elles ont un grand intérêt.
Si tu as des questoins n'hésite pas, je suis à ton entière disposition ;)
Passe une bonne journée
http://www-ipst.u-strasbg.fr/pat/program/tpc05.htm
Là tu as par exemple 2 types de fichiers bruts et bufferisés, dans ce tuto.
Je suis sur qu'il y'en a d'autres.
Je te suggère de tester en utilisant une méthode lseek, et en délimitant par une condition if et stockant dans un tableau les parties pour mieux les traiter.
Tes questions sont pertinentes, elles ont un grand intérêt.
Si tu as des questoins n'hésite pas, je suis à ton entière disposition ;)
Passe une bonne journée
Ce que je ne comprends pas c'est comment fgets marche réellement (bien que j'ai lu le man) : comment accéder à la deuxième ligne du fichier?
Si j'utilise fget(s,1000,fp) deux fois de suite, ne vais-je pas obtenir deux fois la première ligne?
Une autre question : dans un très long fichier, comment accéder à la 500eme ligne rapidement? (sans avoir à lire tous les caractères qui y mènent)
Si j'utilise fget(s,1000,fp) deux fois de suite, ne vais-je pas obtenir deux fois la première ligne?
Une autre question : dans un très long fichier, comment accéder à la 500eme ligne rapidement? (sans avoir à lire tous les caractères qui y mènent)
Bonjour
Si tu ne relis pas deux fois la première ligne, c'est qu'il y a quelque chose qui est mémorisé dans le pointeur de fichier fp (ou plutôt dans la zone pointée). Il y a un compteur qui dit où on en est rendu : il est mis à zéro à l'ouverture du fichier. Quand tu fais un premier fgets, ce compteur est augmenté de la longueur de la ligne. Quand tu viens faire un second fgets, il sait ainsi d'où il doit partir.
Tu ne peux pas sauter directement à la 500ième ligne pour la bonne raison que le seul moyen de savoir où elle commence, c'est de lire tout ce qui précède. Une autre méthode est envisageable si les lignes sont de longueur fixe, évidemment. Mais en général, tu peux avoir des lignes de toutes les longueurs. Si tu ne lis pas tout, comment savoir s'il n'y a pas de saut de ligne dans les parties que tu n'as pas lues ?
Si tu ne relis pas deux fois la première ligne, c'est qu'il y a quelque chose qui est mémorisé dans le pointeur de fichier fp (ou plutôt dans la zone pointée). Il y a un compteur qui dit où on en est rendu : il est mis à zéro à l'ouverture du fichier. Quand tu fais un premier fgets, ce compteur est augmenté de la longueur de la ligne. Quand tu viens faire un second fgets, il sait ainsi d'où il doit partir.
Tu ne peux pas sauter directement à la 500ième ligne pour la bonne raison que le seul moyen de savoir où elle commence, c'est de lire tout ce qui précède. Une autre méthode est envisageable si les lignes sont de longueur fixe, évidemment. Mais en général, tu peux avoir des lignes de toutes les longueurs. Si tu ne lis pas tout, comment savoir s'il n'y a pas de saut de ligne dans les parties que tu n'as pas lues ?
Bonjour,
Merci pour la réponse, qui est complète en soi, mais qui néanmoins soulève d'autres questions.
Peut-on m'expliquer ce mystérieux fp qui mémorise où on en est rendu?
Vu l'explication vague donnée, je n'arrive pas à voir ce qu'il se passerait si un autre programme s'amusait à lire le même fichier au même moment...
Il semblerait qu'il y ait effectivement un problème pour accéder à la 500eme ligne. Mais c'est pas grave car ce n'est pas exactement ce que je veux faire, j'ai simplement mal formulé ma question. En fait, je veux juste accéder au milieu du fichier par exemple (mon but est de chercher, dans un log, une date, par dichotomie, afin de ne pas tout parcourir betement)
Merci pour la réponse, qui est complète en soi, mais qui néanmoins soulève d'autres questions.
Peut-on m'expliquer ce mystérieux fp qui mémorise où on en est rendu?
Vu l'explication vague donnée, je n'arrive pas à voir ce qu'il se passerait si un autre programme s'amusait à lire le même fichier au même moment...
Il semblerait qu'il y ait effectivement un problème pour accéder à la 500eme ligne. Mais c'est pas grave car ce n'est pas exactement ce que je veux faire, j'ai simplement mal formulé ma question. En fait, je veux juste accéder au milieu du fichier par exemple (mon but est de chercher, dans un log, une date, par dichotomie, afin de ne pas tout parcourir betement)
blux
Messages postés
26001
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
24 avril 2024
3 289
2 déc. 2009 à 09:55
2 déc. 2009 à 09:55
Salut,
Vu l'explication vague donnée, je n'arrive pas à voir ce qu'il se passerait si un autre programme s'amusait à lire le même fichier au même moment...
Aucun problème !
A un instant donné, il n'y a qu'un seul programme en exécution à la fois (je parle bien d'exécution, pas de programmes chargés en mémoire), avec chacun sa zone de travail...
Vu l'explication vague donnée, je n'arrive pas à voir ce qu'il se passerait si un autre programme s'amusait à lire le même fichier au même moment...
Aucun problème !
A un instant donné, il n'y a qu'un seul programme en exécution à la fois (je parle bien d'exécution, pas de programmes chargés en mémoire), avec chacun sa zone de travail...
le "fp" n'a rien de mystérieux. C'est une pointeur sur une structure de type FILE (tu as bien du déclarer FILE * fp quelque part). Cette structure FILE est obligatoirement déclarée dans l'un des fichiers que tu inclus, car elle ne fait pas partie du langage C lui-même. Je te recopie ici celle de mon compilateur :
À vue de nez, le champ _cnt est celui dont je te parlais. Mais je ne suis pas un gourou en C, il y a beaucoup de choses que j'ignore. En particulier, je ne sais pas si cette structure est la même d'un compilateur à l'autre. Je suppose que non, les différents OS ayant a priori une gestion différente des fichiers.
Pour l'accès 'simultané' de 2 programmes à un fichier, chacun a sa propre structure FILE et chacun son compteur. Tans qu'on ne fait que de la lecture, aucun problème. C'est si on écrit que ça devient rigolo ;-)
Pour rechercher par dichotomie, il faudrait regarder la documentation de la fonction fseek. Je pense que cela va t'amener à revoir totalement ta façon d'ouvrir et de lire le fichier, mais je ne pratique pas assez le C pour être capable de te répondre à brûle-pourpoint.
struct _iobuf {
char *_ptr;
int _cnt;
char *_base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char *_tmpfname;
};
typedef struct _iobuf FILE;
À vue de nez, le champ _cnt est celui dont je te parlais. Mais je ne suis pas un gourou en C, il y a beaucoup de choses que j'ignore. En particulier, je ne sais pas si cette structure est la même d'un compilateur à l'autre. Je suppose que non, les différents OS ayant a priori une gestion différente des fichiers.
Pour l'accès 'simultané' de 2 programmes à un fichier, chacun a sa propre structure FILE et chacun son compteur. Tans qu'on ne fait que de la lecture, aucun problème. C'est si on écrit que ça devient rigolo ;-)
Pour rechercher par dichotomie, il faudrait regarder la documentation de la fonction fseek. Je pense que cela va t'amener à revoir totalement ta façon d'ouvrir et de lire le fichier, mais je ne pratique pas assez le C pour être capable de te répondre à brûle-pourpoint.
blux
Messages postés
26001
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
24 avril 2024
3 289
2 déc. 2009 à 10:24
2 déc. 2009 à 10:24
C'est si on écrit que ça devient rigolo ;-)
Dans la plupart des OS, c'est le dernier qui écrit qui a raison... les deadlocks ne sont pas (ou mal) gérés...
Dans la plupart des OS, c'est le dernier qui écrit qui a raison... les deadlocks ne sont pas (ou mal) gérés...
Donc comment passer directement au milieu du fichier (par exemple, où au 1000eme caractère, ou à la 1000ème ligne) sans avoir lu tous les précédents?
Comme je te l'ai dit, regarde dans ton manuel la fonction fseek.
fseek (fp, 1000, SEEK_SET);
voir par exemple:
http://www.cplusplus.com/reference/cstdio/fseek/
Mais attention, rien ne dit que tu tomberas sur un début de ligne
fseek (fp, 1000, SEEK_SET);
voir par exemple:
http://www.cplusplus.com/reference/cstdio/fseek/
Mais attention, rien ne dit que tu tomberas sur un début de ligne
heyquem
Messages postés
759
Date d'inscription
mercredi 17 juin 2009
Statut
Membre
Dernière intervention
29 décembre 2013
130
2 déc. 2009 à 19:31
2 déc. 2009 à 19:31
Jennifer,
Tes questions sont très légitimes, et j'aime la rigueur dans laquelle tu les abordes.
Tu risques cependant d'avoir quelque difficulté à trouver les réponses pour deux raisons:
### Ce sont des questions que peu de personnes se posent, en tous cas avec ce souci de rigueur et de précision là, et je trouve aussi les tutoriels, ou autres documents censés expliquer, assez majoritairement évasifs ou confus sur les fondements ultimes quand je me mets à me poser ce genre de questions, ou à l'inverse trop complexes dans lesquels on se perd.
Il est vrai que certaines choses sont sans doute difficilement connaissables.
Je pense que c'est le cas de la façon dont un OS gère les fichiers sur le disque dur et gère les échanges entre le disque dur et la mémoire vive (qui font intervenir un cache ou même deux). Il n'y a peut être que les membres des équipes qui ont réalisé les algorithmes et les implémentations des modules responsables de ces tâches, chez Microsoft, chez Apple, etc, qui pourraient répondre aux questions les plus pointues.
Ou peut être pas. Je n'en sais rien à vrai dire.
Mais je crois qu'il est plus sage, en première approche, de ne pas chercher à résoudre les interrogations dans tous les plans à la fois; en tous cas, de bien faire le distingo entre ce qui relève du fonctionnement d'un OS et ce qui relève de la nature "théorique" d'un fichier, c'est à dire considéré indépendamment de la façon dont il est écrit en disque dur et récupéré par lecture pour être rendu disponible en mémoire vive.
Je ne dis pas que le fonctionnement précis de l'OS n'est pas intéressant mais pour intervenir avec un programme en C dans un fichier, il n'est pas nécessaire de savoir si celui-ci est écrit en plusieurs blocs ou non sur le DD et s'il est stocké entier ou non dans la mémoire vive ou le cache graphique de l'écran: l'OS se débrouille pour le présenter à un programme selon les besoins de ce dernier, et on peut considérer le fichier comme étant d'un seul tenant.
Enfin...bon, je crois qu'il en est ainsi.
Je me méfie, étant donné la nature de C. Il se pourrait qu'il permette de réguler finement les processus matériels, y compris ceux concernant le disque dur. S'il en est ainsi, je veux bien qu'on me contredise en m'expliquant.
De plus, l'étude du langage C demande suffisamment d'effort à elle seule, pour ne pas s'alourdir avec des interrogations impliquant l'activité de l'OS. C'est déjà assez compliqué comme ça, je pense, de comprendre comment un programme en C permet d'intervenir dans un fichier pour repousser à plus tard des questions impliquant l'OS.
### C'est d'ailleurs la deuxième raison de la difficulté à dégager les bonnes réponses concernant les fichiers, si tu t'attaques à ce sujet dans le cadre d'un apprentissage de C:
Le langage C, tout comme C++ et Fortran, est un langage de bas niveau, ce qui signifie proches du hardware (et non pas rudimentaires). De ce fait ils contiennent de nombreux concepts relatifs aux relations avec le hardware, ce qui devrait d'ailleurs entrainer un plus grand souci de cette rigueur et de cette précision que tu souhaites, dans la compréhension de ces concepts.
Malheureusement, cet aspect hardware impose une intendance de nombreux détails de bas-niveau, qui sont nécessaires pour atteindre de grandes vitesses d'exécution, mais qui encombrent la compréhension globale et pénétrante d'un langage et de ce qu'il fait. C'est pire qu'un arbre qui cache la forêt, car il y a quantités d'arbres et plus ou moins compliqués.
Tous ces détails liés au bas-niveau rendent ardu de faire la moindre chose par soi-même, donc de pouvoir tester rapidement des hypothèses, et brouillent la compréhension globale en enveloppant l'essence d'un code par un tas de cérémonies préparatoires et associées.
Quant aux documents de formation, les notions clés sont vite noyées dans un magma de détails matérialistes.
Ainsi donc, à mon avis, se lancer à comprendre les caractéristiques des fichiers et des fonctions liées à leur manipulation dans le cadre d'un apprentissage d'un langage comme C, bonjour le voyage !
Personnellement, j'ai progressé dans cette compréhensiuon des fichiers dans le cadre de l'utilisation de Python et, bien que ce soit un langage de très haut-niveau qui épargne nombre des tracas inhérents aux C, C++, Fortran et compagnie, j'ai eu du mal. Alors avec C ou autre........
-----------------------------------------------------------------------------------------------------
Bon, mais je ne suis pas là pour te démoraliser. On finit toujours par avancer quand on s'acharne.
Ce qu'il serait bon de savoir, Jennifer, c'est quel est ton objectif prioritaire:
- comprendre en profondeur tout ce qui concerne les fichiers par curiosité intellectuelle ?
- comprendre les fichiers comme préalable nécessaire à la réalisation de toute application ?
- ou parvenir aussi relativement rapidement au résultat concret que tu as dit ? :
Ceci dit, voici quand même des éléments de réponses qui devraient t'être utiles, j'espère:
* Je pense que la seule idée à avoir sur l'implication de l'OS est celle-ci, relative aux pointeurs de fichier et aux tête de lecture/écriture d'un disque dur:
Chaque ouverture de fichier crée effectivement un pointeur de fichier qui va être à tout moment positionné quelque part dans le fichier; ce quelque part est l'endroit où commence une action ordonnée par le programme (soit lecture, soit écriture).
Il y a évidemment des fonctions pour obtenir la connaissance de la position d'un pointeur à un moment donné, et pour faire déplacer le pointeur dans le fichier.
Un pointeur est une sorte de tête de lecture-écriture, mais seulement virtuelle.
Concrètement, il existe bien des têtes de lecture/écriture: un disque dur étant en réalité constitué de plusieurs plateaux empilés, il y a plusieurs têtes de lectures/écriture, mais il n'y en a qu'une seule par plateau.
Aussi, s'il est tout à fait possible d'ouvrir plusieurs fois un fichier, donc d'y créer plusieurs pointeurs de fichiers (virtuels), il est par contre logique de penser que si l'on ordonne en même temps deux actions sur un fichier qui doivent être réalisées sur un seul plateau, comme il n'y a qu'une tête, les deux actions ne pourront qu'être effectuées l'une après l'autre; je ne pense pas que ce soit une situation de "dreadlock" = blocage réciproque.
Je ne sais par contre pas si deux têtes de lecture/écriture peuvent fonctionner en même temps sur des plateaux différents, dans le cas où on ordonne deux actions sur un fichier inscrit sur deux plateaux, ou sur deux fichiers différents situés sur des plateaux différents.
* Autre idée à garder à l'esprit:
dans sa forme idéale d'un seul tenant, un fichier n'est physiquement rien d'autre qu'une succession unique et ininterrompue d'octets ayant une signification ==> il n'y a pas de lignes dans un fichier: rien de physique ne correspond à la notion de ligne, qui n'est qu'une notion pratique n'apparaissant que dans le cadre d'un affichage à l'écran ou d'une impression.
Les symboles de fin de ligne, qui provoquent les retours à la ligne lors d'un affichage sont '\r\n' sous Windows, '\n' sous UNIX, '\r' sous Mac (c'est différent pour MacOS X, mais je ne sais pas précisément quoi).
L'une des conséquences est qu'on peut charger un fichier dans une variable chaîne puis faire une recherche de caractères comme dans n'importe quelle chaîne de caractères, sans tenir compte de la présence de caractèes de fin de ligne. Ou en tenant compte des caractères de fin de ligne si le motif recherché en dépend, mais ces fins de ligne n'ont absolument aucune nature différente de celle des autres caractères.
Cette façon de faire, à coup de find() et/ou d'expressions régulières, évite de faire les balourdes lectures de 500 lignes préalables pour obtenir la ligne 501.
On peut ainsi chercher un motif en ne se préoccupant absolument pas de savoir dans quelle ligne il est.
* À mon avis, l'un des points auxquels s'intéresser concernant les fichiers, plus qu'aux caractéristiques de fonctionnement de l'OS, c'est l'encodage d'un fichier de caractères.
* Comme solution à ton problème pratique, tu as deux possibilités à mon sens.
L'une est l'utilisation des "regular expressions". C'est un moyen très puissant de faire des recherches de motifs de caractères dans un fichier de caractères. Pas besoin de te lancer dans une recherche par dichotomie; sauf à titre d'exercice, ou par jeu, ou pour un devoir.
Bien sûr, comme je l'ai décrit plus haut, les broussailles du bas-niveau du langage C risque fort de te barrer le chemin vers l'emploi de cet outil qui n'est pas en lui même tout à fait évident de prime abord.
L'autre est un outil que j'ai découvert tout récemment: sed . Il s'agit d'un éditeur de flux en ligne de commande. Cela ne permet pas des choses aussi sophistiquées que les expressions régulières, mais ça m'a l'air très puissant quand même et je pense que ça peut avoir un usage très intéressant permettant beaucoup de choses sans avoir à utiliser un programme proprement dit.
Un exemple de résolution du problème d'un forumeur grâce à sed, ici:
https://forums.commentcamarche.net/forum/affich-15356314-modifier-une-phrase-dans-un-fichier-txt#17
Enfin, quand je vois la complication de la première page du tutoriel sur les expressions régulières en C sur le site developpez.com, je me demande comment on peut avoir le courage de rentrer dans ce domaine et je ne peux pas m'empêcher de signaler qu'en Python par contre, les expressions régulières se pratiquent avec beaucoup de facilité de mise en place. Ce qui fait que si on a un objectif pratique en vue, on peut parfaitement à mon avis se lancer dans l'apprentissage du minimum de Python nécessaire pour réaliser un traitement de texte. Question facilité, je ne parle pas de l'écriture de la chaîne de caractères qui doit constituer la base d'un objet 'regex", mais de la mise en œuvre des fonctions de recherche par expressions régulières. Donc ça fait une troisième solution, en fait.
NB: si je parle de la plus grande facilité à faire des choses en Python, ce n'est pas pour dénigrer C. En réalité Python est écrit en C, et j'ai moi même l'intention d'apprendre C pour mieux comprendre les aspects bas-niveau. Mais il faut bien reconnaître que Python permet d'apprendre un domaine plus facilement et rapidement et d'aboutir à des programmes non primaires en beaucoup moins de temps.
Tes questions sont très légitimes, et j'aime la rigueur dans laquelle tu les abordes.
Tu risques cependant d'avoir quelque difficulté à trouver les réponses pour deux raisons:
### Ce sont des questions que peu de personnes se posent, en tous cas avec ce souci de rigueur et de précision là, et je trouve aussi les tutoriels, ou autres documents censés expliquer, assez majoritairement évasifs ou confus sur les fondements ultimes quand je me mets à me poser ce genre de questions, ou à l'inverse trop complexes dans lesquels on se perd.
Il est vrai que certaines choses sont sans doute difficilement connaissables.
Je pense que c'est le cas de la façon dont un OS gère les fichiers sur le disque dur et gère les échanges entre le disque dur et la mémoire vive (qui font intervenir un cache ou même deux). Il n'y a peut être que les membres des équipes qui ont réalisé les algorithmes et les implémentations des modules responsables de ces tâches, chez Microsoft, chez Apple, etc, qui pourraient répondre aux questions les plus pointues.
Ou peut être pas. Je n'en sais rien à vrai dire.
Mais je crois qu'il est plus sage, en première approche, de ne pas chercher à résoudre les interrogations dans tous les plans à la fois; en tous cas, de bien faire le distingo entre ce qui relève du fonctionnement d'un OS et ce qui relève de la nature "théorique" d'un fichier, c'est à dire considéré indépendamment de la façon dont il est écrit en disque dur et récupéré par lecture pour être rendu disponible en mémoire vive.
Je ne dis pas que le fonctionnement précis de l'OS n'est pas intéressant mais pour intervenir avec un programme en C dans un fichier, il n'est pas nécessaire de savoir si celui-ci est écrit en plusieurs blocs ou non sur le DD et s'il est stocké entier ou non dans la mémoire vive ou le cache graphique de l'écran: l'OS se débrouille pour le présenter à un programme selon les besoins de ce dernier, et on peut considérer le fichier comme étant d'un seul tenant.
Enfin...bon, je crois qu'il en est ainsi.
Je me méfie, étant donné la nature de C. Il se pourrait qu'il permette de réguler finement les processus matériels, y compris ceux concernant le disque dur. S'il en est ainsi, je veux bien qu'on me contredise en m'expliquant.
De plus, l'étude du langage C demande suffisamment d'effort à elle seule, pour ne pas s'alourdir avec des interrogations impliquant l'activité de l'OS. C'est déjà assez compliqué comme ça, je pense, de comprendre comment un programme en C permet d'intervenir dans un fichier pour repousser à plus tard des questions impliquant l'OS.
### C'est d'ailleurs la deuxième raison de la difficulté à dégager les bonnes réponses concernant les fichiers, si tu t'attaques à ce sujet dans le cadre d'un apprentissage de C:
Le langage C, tout comme C++ et Fortran, est un langage de bas niveau, ce qui signifie proches du hardware (et non pas rudimentaires). De ce fait ils contiennent de nombreux concepts relatifs aux relations avec le hardware, ce qui devrait d'ailleurs entrainer un plus grand souci de cette rigueur et de cette précision que tu souhaites, dans la compréhension de ces concepts.
Malheureusement, cet aspect hardware impose une intendance de nombreux détails de bas-niveau, qui sont nécessaires pour atteindre de grandes vitesses d'exécution, mais qui encombrent la compréhension globale et pénétrante d'un langage et de ce qu'il fait. C'est pire qu'un arbre qui cache la forêt, car il y a quantités d'arbres et plus ou moins compliqués.
Tous ces détails liés au bas-niveau rendent ardu de faire la moindre chose par soi-même, donc de pouvoir tester rapidement des hypothèses, et brouillent la compréhension globale en enveloppant l'essence d'un code par un tas de cérémonies préparatoires et associées.
Quant aux documents de formation, les notions clés sont vite noyées dans un magma de détails matérialistes.
Ainsi donc, à mon avis, se lancer à comprendre les caractéristiques des fichiers et des fonctions liées à leur manipulation dans le cadre d'un apprentissage d'un langage comme C, bonjour le voyage !
Personnellement, j'ai progressé dans cette compréhensiuon des fichiers dans le cadre de l'utilisation de Python et, bien que ce soit un langage de très haut-niveau qui épargne nombre des tracas inhérents aux C, C++, Fortran et compagnie, j'ai eu du mal. Alors avec C ou autre........
-----------------------------------------------------------------------------------------------------
Bon, mais je ne suis pas là pour te démoraliser. On finit toujours par avancer quand on s'acharne.
Ce qu'il serait bon de savoir, Jennifer, c'est quel est ton objectif prioritaire:
- comprendre en profondeur tout ce qui concerne les fichiers par curiosité intellectuelle ?
- comprendre les fichiers comme préalable nécessaire à la réalisation de toute application ?
- ou parvenir aussi relativement rapidement au résultat concret que tu as dit ? :
J'ai besoin de parser un log en C, et d'y chercher certaines infos. Quels sont les moyens mis à ma disposition? Est-ce que je peux chercher un retour à la ligne (\n), à l'aide d'un fscanf? En fait, je veux juste accéder au milieu du fichier par exemple (mon but est de chercher, dans un log, une date, par dichotomie, afin de ne pas tout parcourir betement)
Ceci dit, voici quand même des éléments de réponses qui devraient t'être utiles, j'espère:
* Je pense que la seule idée à avoir sur l'implication de l'OS est celle-ci, relative aux pointeurs de fichier et aux tête de lecture/écriture d'un disque dur:
Chaque ouverture de fichier crée effectivement un pointeur de fichier qui va être à tout moment positionné quelque part dans le fichier; ce quelque part est l'endroit où commence une action ordonnée par le programme (soit lecture, soit écriture).
Il y a évidemment des fonctions pour obtenir la connaissance de la position d'un pointeur à un moment donné, et pour faire déplacer le pointeur dans le fichier.
Un pointeur est une sorte de tête de lecture-écriture, mais seulement virtuelle.
Concrètement, il existe bien des têtes de lecture/écriture: un disque dur étant en réalité constitué de plusieurs plateaux empilés, il y a plusieurs têtes de lectures/écriture, mais il n'y en a qu'une seule par plateau.
Aussi, s'il est tout à fait possible d'ouvrir plusieurs fois un fichier, donc d'y créer plusieurs pointeurs de fichiers (virtuels), il est par contre logique de penser que si l'on ordonne en même temps deux actions sur un fichier qui doivent être réalisées sur un seul plateau, comme il n'y a qu'une tête, les deux actions ne pourront qu'être effectuées l'une après l'autre; je ne pense pas que ce soit une situation de "dreadlock" = blocage réciproque.
Je ne sais par contre pas si deux têtes de lecture/écriture peuvent fonctionner en même temps sur des plateaux différents, dans le cas où on ordonne deux actions sur un fichier inscrit sur deux plateaux, ou sur deux fichiers différents situés sur des plateaux différents.
* Autre idée à garder à l'esprit:
dans sa forme idéale d'un seul tenant, un fichier n'est physiquement rien d'autre qu'une succession unique et ininterrompue d'octets ayant une signification ==> il n'y a pas de lignes dans un fichier: rien de physique ne correspond à la notion de ligne, qui n'est qu'une notion pratique n'apparaissant que dans le cadre d'un affichage à l'écran ou d'une impression.
Les symboles de fin de ligne, qui provoquent les retours à la ligne lors d'un affichage sont '\r\n' sous Windows, '\n' sous UNIX, '\r' sous Mac (c'est différent pour MacOS X, mais je ne sais pas précisément quoi).
L'une des conséquences est qu'on peut charger un fichier dans une variable chaîne puis faire une recherche de caractères comme dans n'importe quelle chaîne de caractères, sans tenir compte de la présence de caractèes de fin de ligne. Ou en tenant compte des caractères de fin de ligne si le motif recherché en dépend, mais ces fins de ligne n'ont absolument aucune nature différente de celle des autres caractères.
Cette façon de faire, à coup de find() et/ou d'expressions régulières, évite de faire les balourdes lectures de 500 lignes préalables pour obtenir la ligne 501.
On peut ainsi chercher un motif en ne se préoccupant absolument pas de savoir dans quelle ligne il est.
* À mon avis, l'un des points auxquels s'intéresser concernant les fichiers, plus qu'aux caractéristiques de fonctionnement de l'OS, c'est l'encodage d'un fichier de caractères.
* Comme solution à ton problème pratique, tu as deux possibilités à mon sens.
L'une est l'utilisation des "regular expressions". C'est un moyen très puissant de faire des recherches de motifs de caractères dans un fichier de caractères. Pas besoin de te lancer dans une recherche par dichotomie; sauf à titre d'exercice, ou par jeu, ou pour un devoir.
Bien sûr, comme je l'ai décrit plus haut, les broussailles du bas-niveau du langage C risque fort de te barrer le chemin vers l'emploi de cet outil qui n'est pas en lui même tout à fait évident de prime abord.
L'autre est un outil que j'ai découvert tout récemment: sed . Il s'agit d'un éditeur de flux en ligne de commande. Cela ne permet pas des choses aussi sophistiquées que les expressions régulières, mais ça m'a l'air très puissant quand même et je pense que ça peut avoir un usage très intéressant permettant beaucoup de choses sans avoir à utiliser un programme proprement dit.
Un exemple de résolution du problème d'un forumeur grâce à sed, ici:
https://forums.commentcamarche.net/forum/affich-15356314-modifier-une-phrase-dans-un-fichier-txt#17
Enfin, quand je vois la complication de la première page du tutoriel sur les expressions régulières en C sur le site developpez.com, je me demande comment on peut avoir le courage de rentrer dans ce domaine et je ne peux pas m'empêcher de signaler qu'en Python par contre, les expressions régulières se pratiquent avec beaucoup de facilité de mise en place. Ce qui fait que si on a un objectif pratique en vue, on peut parfaitement à mon avis se lancer dans l'apprentissage du minimum de Python nécessaire pour réaliser un traitement de texte. Question facilité, je ne parle pas de l'écriture de la chaîne de caractères qui doit constituer la base d'un objet 'regex", mais de la mise en œuvre des fonctions de recherche par expressions régulières. Donc ça fait une troisième solution, en fait.
NB: si je parle de la plus grande facilité à faire des choses en Python, ce n'est pas pour dénigrer C. En réalité Python est écrit en C, et j'ai moi même l'intention d'apprendre C pour mieux comprendre les aspects bas-niveau. Mais il faut bien reconnaître que Python permet d'apprendre un domaine plus facilement et rapidement et d'aboutir à des programmes non primaires en beaucoup moins de temps.
blux
Messages postés
26001
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
24 avril 2024
3 289
Modifié le 10 déc. 2009 à 16:51
Modifié le 10 déc. 2009 à 16:51
comme il n'y a qu'une tête, les deux actions ne pourront qu'être effectuées l'une après l'autre; je ne pense pas que ce soit une situation de "dreadlock" = blocage réciproque.
Les dreadlocks, c'est chez les jamaïcains ;-) en informatique, on appelle cela 'deadlock' ou 'deadly embrace', soit 'étreinte fatale' dans la langue de Molière...
Mais si on peut s'interbloquer même avec une seule tête de lecture (soit dit en passant, les têtes sont sur un seul bras, elles bougent donc de la même manière, c'est pourquoi les informations sont stockées sous forme de 'cylindres', quand une tête lit un bit, celles du dessous lisent les suivants, on gagne donc du temps, puisque les données sont accédées sans attendre le tour suivant du disque dur).
Le blocage survient lorsque l'on fait des mises à jour de beaucoup de secteurs disques. Les processus en machine n'ont pas un temps d'exécution illimité, mais sont contraints par le processus de dispatching à laisser leur place de temps en temps : soit parce qu'ils ont envoyé une I/O et qu'ils en attendent le retour, soit parce qu'ils ont dépassé leur quantum de temps (un processus prioritaire aura un quantum plus élevé qu'un processus tout-venant). Dans ces deux cas, le dispatcheur reprend la main et la donne à un autre processus, et ainsi de suite. Mais il peut arriver qu'un processus qui fonctionne avec des transactions (comme une grosse mise à jour de base via SQL) veuille mettre à jour un nombre de secteurs très important sur disque, il va commencer à écrire en mettant des verrous sur les secteurs dont il aura besoin ; à un moment il va se faire couper la chique par le dispatcheur pour le processus suivant (qui est du même type : grosse mise à jour avec transaction). Le processus suivant va donc commencer son écriture, mais au bout d'un moment il aura besoin d'écrire là où le processus précédent a déjà écrit, mais il ne peut pas, car les secteurs ont un verrou de positionné, il est donc en attente que les secteurs se libèrent, mais il garde les verrous sur ses secteurs. Le processus précédent va revenir en exécution (quand ce sera son tour), et c'est là qu'il aura besoin des secteurs déjà verrouillés par le processus suivant. Vu que l'on est dans un environnement de transaction (type ACID), aucun des processus ne voudra continuer ses mises à jour, car pour garantir une cohérence, c'est tout ou rien. Donc on se retrouve avec le processus A qui a écrit sur S1, S2, S3 et qui attend S4, avec le processus B, qui a écrit sur S6, S5, S4 et qui attend S1 : on est en plein 'deadlock'. La situation peut durer jusqu'à ce que mort s'en suive, ou qu'un processus spécial demande à l'un des processus d'abandonner de qu'il a déjà fait (rollback) afin de débloquer la situation, puis de se relancer une fois les écritures de l'autre processus terminées...
Ouf...c'est à peu près clair ? ;-)
Les dreadlocks, c'est chez les jamaïcains ;-) en informatique, on appelle cela 'deadlock' ou 'deadly embrace', soit 'étreinte fatale' dans la langue de Molière...
Mais si on peut s'interbloquer même avec une seule tête de lecture (soit dit en passant, les têtes sont sur un seul bras, elles bougent donc de la même manière, c'est pourquoi les informations sont stockées sous forme de 'cylindres', quand une tête lit un bit, celles du dessous lisent les suivants, on gagne donc du temps, puisque les données sont accédées sans attendre le tour suivant du disque dur).
Le blocage survient lorsque l'on fait des mises à jour de beaucoup de secteurs disques. Les processus en machine n'ont pas un temps d'exécution illimité, mais sont contraints par le processus de dispatching à laisser leur place de temps en temps : soit parce qu'ils ont envoyé une I/O et qu'ils en attendent le retour, soit parce qu'ils ont dépassé leur quantum de temps (un processus prioritaire aura un quantum plus élevé qu'un processus tout-venant). Dans ces deux cas, le dispatcheur reprend la main et la donne à un autre processus, et ainsi de suite. Mais il peut arriver qu'un processus qui fonctionne avec des transactions (comme une grosse mise à jour de base via SQL) veuille mettre à jour un nombre de secteurs très important sur disque, il va commencer à écrire en mettant des verrous sur les secteurs dont il aura besoin ; à un moment il va se faire couper la chique par le dispatcheur pour le processus suivant (qui est du même type : grosse mise à jour avec transaction). Le processus suivant va donc commencer son écriture, mais au bout d'un moment il aura besoin d'écrire là où le processus précédent a déjà écrit, mais il ne peut pas, car les secteurs ont un verrou de positionné, il est donc en attente que les secteurs se libèrent, mais il garde les verrous sur ses secteurs. Le processus précédent va revenir en exécution (quand ce sera son tour), et c'est là qu'il aura besoin des secteurs déjà verrouillés par le processus suivant. Vu que l'on est dans un environnement de transaction (type ACID), aucun des processus ne voudra continuer ses mises à jour, car pour garantir une cohérence, c'est tout ou rien. Donc on se retrouve avec le processus A qui a écrit sur S1, S2, S3 et qui attend S4, avec le processus B, qui a écrit sur S6, S5, S4 et qui attend S1 : on est en plein 'deadlock'. La situation peut durer jusqu'à ce que mort s'en suive, ou qu'un processus spécial demande à l'un des processus d'abandonner de qu'il a déjà fait (rollback) afin de débloquer la situation, puis de se relancer une fois les écritures de l'autre processus terminées...
Ouf...c'est à peu près clair ? ;-)
osont
>
blux
Messages postés
26001
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
24 avril 2024
2 déc. 2009 à 21:36
2 déc. 2009 à 21:36
Pas mieus,
un fichier: est un code binaire qui défini des places adresses sur dd pour stocker l' info du fichier , début info fin .
Allez y moquer vous,pas grave.
monsieur avraisdirecherpas
un fichier: est un code binaire qui défini des places adresses sur dd pour stocker l' info du fichier , début info fin .
Allez y moquer vous,pas grave.
monsieur avraisdirecherpas
blux
Messages postés
26001
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
24 avril 2024
3 289
>
osont
2 déc. 2009 à 21:47
2 déc. 2009 à 21:47
???
heyquem
Messages postés
759
Date d'inscription
mercredi 17 juin 2009
Statut
Membre
Dernière intervention
29 décembre 2013
130
2 déc. 2009 à 22:43
2 déc. 2009 à 22:43
Blux, c'est très clair, précis et intéressant, oui.
Je comprends maintenant la motivation de la structure en cylindres, que je connaissais...avant de l'avoir oubliée.
Par contre, j'ignorais à ce niveau de précision l'existence d'un "gérant" de disque dur aussi sourcilleux et pour tout dire mal fait, je trouve.
Les systèmes les plus modernes sont ils toujours entachés de cette possibilité fâcheuse de se bloquer à cause d'un deadlock ?
Mais si j'ai bien compris, l'éventualité d'un deadlock est lié à des opérations de type "transactions". En dehors d'opérations liées à l'utilisation d'une BD, les autres opérations de lecture-écriture banales de fichier peuvent elles être de nature "transactionnelle" ? Je me demande.
En tous cas, le fonctionnement par temps fragmenté en durées controlées me donne à penser qu'il faut peut être faire attention si dans un programme on veut utiliser deux pointeurs pour effectuer des manipulations complexes. Si une recherche de caractères dans une chaîne censée venant d'être écrite est lancée alors que l'écriture de la chaîne s'est interrompue, cela mène tout droit à des erreurs de mise en défaut de l'algorithme. Il doit être sage de prévoir des contrôles pour des cas complexes.
Le sujet des deadlocks n'est pas anodin:
http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci211913,00.html
Pour ma confusion avec les dreadlocks, j'ai à ma décharge que la moitié des 10 premières réponses Google sur ce mot concernent le groupe de hard rock heavy metal Deadlock , ce qui a fait dériver mon esprit vers la Jamaïque, car j'avoue que je connaissais beaucoup plus Bob Marley que ce groupe allemand miteux.
Merci pour tes explication blux.
C'est dommage que Jennifer ne les ait pas eues plus tôt.
Je comprends maintenant la motivation de la structure en cylindres, que je connaissais...avant de l'avoir oubliée.
Par contre, j'ignorais à ce niveau de précision l'existence d'un "gérant" de disque dur aussi sourcilleux et pour tout dire mal fait, je trouve.
Les systèmes les plus modernes sont ils toujours entachés de cette possibilité fâcheuse de se bloquer à cause d'un deadlock ?
Mais si j'ai bien compris, l'éventualité d'un deadlock est lié à des opérations de type "transactions". En dehors d'opérations liées à l'utilisation d'une BD, les autres opérations de lecture-écriture banales de fichier peuvent elles être de nature "transactionnelle" ? Je me demande.
En tous cas, le fonctionnement par temps fragmenté en durées controlées me donne à penser qu'il faut peut être faire attention si dans un programme on veut utiliser deux pointeurs pour effectuer des manipulations complexes. Si une recherche de caractères dans une chaîne censée venant d'être écrite est lancée alors que l'écriture de la chaîne s'est interrompue, cela mène tout droit à des erreurs de mise en défaut de l'algorithme. Il doit être sage de prévoir des contrôles pour des cas complexes.
Le sujet des deadlocks n'est pas anodin:
Learning to deal with deadlocks had a major impact on the development of operating systems and the structure of databases. Data was structured and the order of requests was constrained in order to avoid creating deadlocks.
http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci211913,00.html
Pour ma confusion avec les dreadlocks, j'ai à ma décharge que la moitié des 10 premières réponses Google sur ce mot concernent le groupe de hard rock heavy metal Deadlock , ce qui a fait dériver mon esprit vers la Jamaïque, car j'avoue que je connaissais beaucoup plus Bob Marley que ce groupe allemand miteux.
Merci pour tes explication blux.
C'est dommage que Jennifer ne les ait pas eues plus tôt.
