Exam in UNIX Implementation and Integration

Ce sujet d'examen porte sur l'implémentation et l'intégration UNIX. Il évalue les compétences en gestion des fichiers, systèmes de fichiers, programmation système en C, ainsi que la maîtrise des outils de compilation et de débogage.

Exercice 1 : Comparaisons d'implantation de fichiers

Il s'agit d'analyser quatre représentations différentes de la localisation d'un fichier et de déterminer quelles propositions sont vérifiées pour chacune.

Représentation a) : Couple <numéro du premier bloc, nombre de blocs>

• Proposition 1 : La taille totale du fichier doit être connue lors de sa création.

En effet, ici, on donne explicitement le nombre de blocs, donc la taille doit être connue à la création.

• Proposition 2 : Aucune information de taille n'est nécessaire lors de la création.

Faux, car le nombre de blocs est donné, donc la taille est nécessaire.

• Proposition 4 : L'accès aléatoire à un bloc quelconque demande un seul accès disque.

Vrai, car le fichier est contigu, on calcule directement le bloc à partir du premier numéro.

• Proposition 5 : L'accès aléatoire demande au plus 4 accès disque.

Non applicable, car un seul accès suffit.

• Proposition 6 : L'allocation d'espace peut se faire par blocs individuels.

Non, car les blocs sont contigus, allocation en un seul segment.

Réponses cochées : 1, 4

Représentation b) : Couple <numéro du premier bloc, numéro du dernier bloc> avec chaînage des blocs entre eux

• Proposition 1 : La taille totale doit être connue à la création.

Non, car on ne connaît que les extrémités, la taille peut être déduite en parcourant la chaîne.

• Proposition 2 : Aucune information de taille n'est nécessaire.

Vrai, la taille n'est pas nécessaire à la création, on suit les liens.

• Proposition 4 : Accès aléatoire en un seul accès disque.

Faux, il faut parcourir la chaîne jusqu'au bloc demandé.

• Proposition 5 : Accès aléatoire au plus 4 accès disque.

Faux, le nombre d'accès dépend du nombre de blocs chaînés, potentiellement plus que 4.

• Proposition 6 : Allocation par blocs individuels possible.

Vrai, chaque bloc est indépendant et chaîné.

Réponses cochées : 2, 6

Représentation c) : Ensemble de 24 couples <numéro de bloc, nombre de blocs>

• Proposition 1 : Taille totale connue à la création.

Oui, car on connaît le nombre de blocs dans chaque couple, donc la taille totale est connue.

• Proposition 2 : Aucune information de taille nécessaire.

Faux, la taille est connue via les couples.

• Proposition 4 : Accès aléatoire en un seul accès disque.

Faux, il faut localiser le couple contenant le bloc demandé.

• Proposition 5 : Accès aléatoire au plus 4 accès disque.

Vrai, car avec 24 couples, on peut accéder en quelques accès (exemple: 4 accès max).

• Proposition 6 : Allocation par blocs individuels possible.

Vrai, car les blocs sont regroupés en segments, mais segments multiples possibles.

Réponses cochées : 1, 5, 6

Représentation d) : Ensemble de 13 numéros de blocs avec niveaux d'indirection

• Proposition 1 : Taille totale connue à la création.

Non, la taille est déterminée en suivant les pointeurs indirects.

• Proposition 2 : Aucune information de taille nécessaire.

Vrai, la taille peut être déduite en parcourant les blocs.

• Proposition 4 : Accès aléatoire en un seul accès disque.

Faux, il faut suivre jusqu'à 4 niveaux d'indirection.

• Proposition 5 : Accès aléatoire au plus 4 accès disque.

Vrai, car la structure comporte 3 niveaux d'indirection plus le bloc de données, soit 4 accès max.

• Proposition 6 : Allocation par blocs individuels possible.

Vrai, allocation par blocs dispersés possible via les pointeurs.

Réponses cochées : 2, 5, 6

Exercice 2 : Système de Gestion de Fichiers (SGF)

On étudie un disque de 64 secteurs avec un SGF similaire au FFS UNIX. Les 16 premiers secteurs sont réservés à la table des i-nœuds. Chaque secteur contient 4 mots de 4 octets. Un i-nœud occupe un secteur et contient 2 pointeurs directs, 1 pointeur indirect, et 1 double pointeur indirect.

Question 1 : Taille (en secteurs) du fichier décrit par l’i-noeud 1

Pour répondre, il faudrait connaître les blocs pointés par l’i-noeud 1. L’énoncé ne fournit pas ces informations.

Impossible de répondre faute d’informations sur les pointeurs de l’i-noeud 1.

Question 2 : Taille (en secteurs) du fichier décrit par l’i-noeud 4

Même remarque que pour la question 1, les données sur les pointeurs ne sont pas fournies.

Impossible de répondre faute d’informations sur les pointeurs de l’i-noeud 4.

Question 3 : Liste des noms de fichiers pour le répertoire racine

Le répertoire racine est 0, mais la liste des fichiers n’est pas donnée dans l’énoncé.

Impossible de répondre faute de données sur le contenu du répertoire racine.

Question 4 : Quel est l’i-noeud du fichier /MARY/ABLE ?

Sans la table des répertoires et des i-noeuds, cette information ne peut être déterminée.

Impossible de répondre faute d’informations sur les répertoires.

Question 5 : Que faire si j'ai bien lu l'intégralité du fichier /ME/WAS ?

Sans plus de détails sur la structure du fichier, on peut seulement dire que la lecture complète implique de suivre tous les pointeurs directs et indirects jusqu’à la fin.

La lecture complète nécessite d’accéder à tous les blocs pointés par les pointeurs directs, indirects et double indirects de l’i-noeud correspondant.

Question 6 : Ce système de fichiers peut-il supporter les liens symboliques ? Pourquoi ?

Le système utilise des i-noeuds avec pointeurs directs et indirects, ce qui est compatible avec la gestion des liens symboliques. Cependant, l’énoncé ne mentionne pas explicitement la prise en charge des liens symboliques.

Le système peut potentiellement supporter les liens symboliques car il utilise une structure d’i-noeuds similaire à UNIX, mais l’énoncé ne donne pas d’informations précises sur leur gestion.

Exercice 3 : Programmation système

Utilisation des appels systèmes open, read, write, close et stat pour deux programmes en C.

Question 1 : Vérifier qu’un fichier passé en argument est accessible uniquement en lecture et écriture pour le propriétaire

Il faut utiliser l’appel stat pour récupérer les droits du fichier, puis tester les bits de permission.

#include <sys/stat.h>
#include <stdio.h>

int verifier_droits(const char *fichier) {
    struct stat st;
    if (stat(fichier, &st) == -1) {
        perror("stat");
        return 0; // Erreur
    }
    // Vérifier que le propriétaire a lecture et écriture
    int lecture_ecriture = ((st.st_mode & S_IRUSR) != 0) && ((st.st_mode & S_IWUSR) != 0);
    // Vérifier que les autres n'ont pas de droits
    int autres_nuls = ((st.st_mode & (S_IRGRP | S_IWGRP | S_IXGRP | S_IROTH | S_IWOTH | S_IXOTH)) == 0);
    if (lecture_ecriture && autres_nuls) {
        return 1; // OK
    } else {
        return 0; // Non conforme
    }
}

Ce code vérifie que seul le propriétaire a les droits lecture et écriture, les autres n’ont aucun droit.

Question 2 : Dupliquer un fichier en remplaçant tous les caractères minuscules par des majuscules

Il faut ouvrir le fichier source en lecture, le fichier cible en écriture, lire par blocs, convertir les caractères, puis écrire.

#include <fcntl.h>
#include <unistd.h>
#include <ctype.h>
#include <stdio.h>>

#define TAILLE_BUF 1024

int dupliquer_majuscule(const char *src, const char *dest) {
    int fd_src = open(src, O_RDONLY);
    if (fd_src < 0) {
        perror("open src");
        return -1;
    }
    int fd_dest = open(dest, O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (fd_dest < 0) {
        perror("open dest");
        close(fd_src);
        return -1;
    }
    char buf[TAILLE_BUF];
    ssize_t lu;
    while ((lu = read(fd_src, buf, TAILLE_BUF)) > 0) {
        for (ssize_t i = 0; i < lu; i++) {
            if (buf[i] >= 'a' && buf[i] <= 'z') {
                buf[i] = buf[i] - 'a' + 'A';
            }
        }
        if (write(fd_dest, buf, lu) != lu) {
            perror("write");
            close(fd_src);
            close(fd_dest);
            return -1;
        }
    }
    if (lu < 0) {
        perror("read");
    }
    close(fd_src);
    close(fd_dest);
    return (lu < 0) ? -1 : 0;
}

Ce code copie le fichier source vers la cible en convertissant les minuscules en majuscules.

Exercice 4 : Outils make, gdb, …

Question 1 : Fichier Makefile pour construire le programme « commande »

Le programme « commande » est composé de commande.c (avec main), util.c, commun.c et la bibliothèque libfichier.a. Les fichiers incluent les headers indiqués. Le compilateur est gcc avec options ANSI C, tous les warnings comme erreurs.

CC = gcc
CFLAGS = -ansi -Wall -Werror
LIBS = -L. -lfichier

OBJ = commande.o util.o commun.o

commande: $(OBJ)
	$(CC) $(CFLAGS) -o commande $(OBJ) $(LIBS)

commande.o: commande.c commun.h util.h fichier.h
	$(CC) $(CFLAGS) -c commande.c

util.o: util.c commun.h util.h
	$(CC) $(CFLAGS) -c util.c

commun.o: commun.c commun.h fichier.h
	$(CC) $(CFLAGS) -c commun.c

clean:
	rm -f *.o commande

Ce Makefile compile les sources avec les options demandées et lie la bibliothèque libfichier.a.

Question 2 : Modifier le Makefile pour pouvoir déboguer avec gdb

Il faut ajouter l’option -g aux CFLAGS pour inclure les informations de débogage.

CFLAGS = -ansi -Wall -Werror -g

L’ajout de -g permet d’utiliser gdb pour le débogage du programme.

Méthode

Ce sujet récompense une bonne compréhension des structures de fichiers et des systèmes de fichiers UNIX, ainsi que la capacité à raisonner sur les accès disque et les allocations. En programmation système, la maîtrise des appels système et la gestion des erreurs sont essentielles. Enfin, la maîtrise des outils de compilation et débogage est évaluée.

Les erreurs fréquentes à éviter sont :

• Ne pas justifier les réponses aux questions théoriques.
• Omettre les étapes de raisonnement dans les calculs ou analyses.
• Ne pas vérifier les droits ou les erreurs lors des appels système.
• Oublier les dépendances dans le Makefile ou ne pas inclure les options de compilation demandées.

Une réponse complète et argumentée, accompagnée de codes clairs et commentés, est la clé du succès.