I.3) Joker :-)
A priori, je pense que le signal sera noté dans le contexte noyau du processus (structure proc ?) mais il faudra attendre un changement de processus pour qu'il y ait une lecture de cette info...
(Voir l'ordonnancement des processus)
I.4) Faux SI les processus n'appartiennent pas au même groupe (voir appel systeme setsid & co) car le process init est le père qui adopte tous les petits orphelins du système.
I.5) Vrai sinon le CTRL+C deviendrait moins amusant dans le SHELL ;-)
I.6) Faux SI { on reste sur le même système de fichier ET le système de fichier gère les liens HARD+SOFT }.
En effet, le lien Symbolique [http://en.wikipedia.org/wiki/Symbolic_link] est composé:
a) 1 entrée dans le listing du répertoire (nom, infos du fichier: inode)
b) 1 contenu (bloc(s) sur le disque) qui correspond au chemin du lien;
De son côté, le lien Hard [http://en.wikipedia.org/wiki/Hard_link] est uniquement composé du a) avec incrément du ref count sur le fichier :-)
Exercice 2
II.1) Je pencherais sur la "portabilité" des appels haut niveau qui feront l'interface avec les appels systèmes "bas niveau" de chaque OS.
La rapiditié revient à l'utilisation du bas niveau qui enlève certaines couches intermédiaires (buffers, structures...)
III.1) les fonctions *dir: opendir, readdir, closedir
Il faut que le répertoire soit accessible par l'utilisateur en Read+eXecute
III.2) On rajoute les fonctions *stat (stat, fstat, lstat, ...) pour chaque entrée afin d'avoir leurs "attributs" (droits d'accès, dates systèmes, ...).
III.3) Joker
Bug de l'implémentation de la commande LS utilisée ;-)
# Trop tard ?!?
Posté par Steve Azriel . En réponse au message Questions d'exam. Évalué à 1.
Quizz me voilà (avec l'aide de WikiPedia :P)
I - Exercice 1
I.1) Vrai sauf cas particulier des commandes types SU ou SUDO & co :-)
I.2) Vrai avec l'aide de Wikipedia [http://en.wikipedia.org/wiki/SIGPIPE]
I.3) Joker :-)
A priori, je pense que le signal sera noté dans le contexte noyau du processus (structure proc ?) mais il faudra attendre un changement de processus pour qu'il y ait une lecture de cette info...
(Voir l'ordonnancement des processus)
I.4) Faux SI les processus n'appartiennent pas au même groupe (voir appel systeme setsid & co) car le process init est le père qui adopte tous les petits orphelins du système.
I.5) Vrai sinon le CTRL+C deviendrait moins amusant dans le SHELL ;-)
I.6) Faux SI { on reste sur le même système de fichier ET le système de fichier gère les liens HARD+SOFT }.
En effet, le lien Symbolique [http://en.wikipedia.org/wiki/Symbolic_link] est composé:
a) 1 entrée dans le listing du répertoire (nom, infos du fichier: inode)
b) 1 contenu (bloc(s) sur le disque) qui correspond au chemin du lien;
De son côté, le lien Hard [http://en.wikipedia.org/wiki/Hard_link] est uniquement composé du a) avec incrément du ref count sur le fichier :-)
Exercice 2
II.1) Je pencherais sur la "portabilité" des appels haut niveau qui feront l'interface avec les appels systèmes "bas niveau" de chaque OS.
La rapiditié revient à l'utilisation du bas niveau qui enlève certaines couches intermédiaires (buffers, structures...)
II.2) WikiPedia:
[http://fr.wikipedia.org/wiki/R%C3%A9entrance]
II.3) WikiPedia:
[http://fr.wikipedia.org/wiki/Attente_passive]
[http://fr.wikipedia.org/wiki/Attente_active]
III - Exercice 3
III.1) les fonctions *dir: opendir, readdir, closedir
Il faut que le répertoire soit accessible par l'utilisateur en Read+eXecute
III.2) On rajoute les fonctions *stat (stat, fstat, lstat, ...) pour chaque entrée afin d'avoir leurs "attributs" (droits d'accès, dates systèmes, ...).
III.3) Joker
Bug de l'implémentation de la commande LS utilisée ;-)
Voili voilà.
Bon courage !
Cdlt,