docs: compte rendu 1 sur la répartition des taches

Doxyfile

@@ -68,7 +68,7 @@ PROJECT_LOGO           =
 # entered, it will be relative to the location where doxygen was started. If
 # left blank the current directory will be used.
 
-OUTPUT_DIRECTORY       = ./docs
+OUTPUT_DIRECTORY       = ./docs/doxygen
 
 # If the CREATE_SUBDIRS tag is set to YES then doxygen will create up to 4096
 # sub-directories (in 2 levels) under the output directory of each output format

docs/compte_rendus/compte_rendu_1.md

@@ -0,0 +1,159 @@
+<p align="right">
+  <img src="../img/logo_isty.png" alt="Logo ISTY" width="180"/>
+</p>
+
+# Rapport d’analyse et de conception
+
+## Projet Système 2025/2026 – Système de Gestion de Fichiers (SGF)
+
+**Membres de l’équipe :**
+- CHOISY Alexis
+- DEGAT Teddy
+- DA SILVA FERREIRA Lucas
+- FOURNIE Baptiste
+- [Nom Étudiant 5]
+
+**Encadrante :** ABOUDA Dhekra  
+**Date de remise :** 20 avril 2026
+
+---
+
+## Sommaire
+- [I. Analyse des besoins de l’utilisateur](#i-analyse-des-besoins-de-lutilisateur)
+- [II. Définition du système à réaliser](#ii-définition-du-système-à-réaliser)
+- [III. Cahier des charges](#iii-cahier-des-charges)
+- [IV. Structures de données prévues](#iv-structures-de-données-prévues)
+- [V. Liste des fonctions principales](#v-liste-des-fonctions-principales)
+- [VI. Répartition des tâches](#vi-répartition-des-tâches)
+- [VII. Conclusion](#vii-conclusion)
+
+---
+
+## I. Analyse des besoins de l’utilisateur
+
+### 1. Objectifs fonctionnels
+Le programme doit permettre à un utilisateur de :
+- Interagir via un shell.
+- Gérer une arborescence de fichiers et répertoires (création, suppression, déplacement).
+- Manipuler le contenu des fichiers (lecture, écriture) via des primitives spécifiques.
+- Assurer la persistance des données par la sauvegarde/recharge du SGF sur le disque physique.
+
+### 2. Contraintes
+- **Langage** : C uniquement.
+- **Dates limites** : Rendu de l'analyse le 20 avril 2026, conception le 2 mai 2026, et final le 28 mai 2026.
+
+---
+
+## II. Définition du système à réaliser
+
+### 1. Fonctionnement général
+Le système simule une partition de disque dur à travers un fichier. Il s'articule autour de trois couches:
+1. **Le Shell** : Analyse les commandes (`ls`, `mkdir`, etc.) et appelle les primitives.
+2. **Les Primitives** : Fonctions de bas niveau (`myopen`, `myread`) qui font le lien avec la structure interne.
+3. **Le SGF** : Gère l'organisation physique des i-nodes et des blocs de données.
+
+![illustration](../img/comment_ça_fonctionne.png)
+
+
+---
+
+## III. Cahier des charges
+
+### 1. Description globale des fonctions
+
+| Fonctionnalité | Description |
+| :--- | :--- |
+| **Shell** | Gère les commandes `ls`, `mkdir`, `rmdir`, `cat`, `cp`, `rm`, `mv`. |
+| **Gestion Inodes** | Attribution et libération d'i-nodes pour fichiers et répertoires. |
+| **Gestion Blocs** | Allocation de blocs de données (contigus ou non) pour le stockage. |
+| **Arborescence** | Gestion des répertoires comme des fichiers spéciaux listant des i-nodes. |
+| **Persistance** | Sauvegarde de l'état complet du disque virtuel dans un fichier binaire. |
+| **Superbloc (df)** | Fournit les infos sur les blocs/inodes libres et l'espace disque. |
+
+### 2. Fonctions bonus
+- Gestion de plusieurs utilisateurs simultanés.
+- Implémentation des filtres `grep` et `find`.
+- Gestion des droits d'accès et dates de modification sur les inodes.
+
+---
+
+## IV. Structures de données prévues
+
+Le SGF utilise des structures à taille fixe pour simuler la partition .
+
+```c
+/**
+ * @struct inode
+ * @brief Un inode est un fichier, il possède des permissions, un type (répertoire par exemple) et pointe sur des blocs de données
+ */
+typedef struct inode {
+  unsigned short perms; // rwxrwxrwx
+  char filetype;
+  int blocs[MAX_BLOCS];
+} inode;
+
+/**
+ * @struct bloc
+ * @brief Un bloc possède un tableau de données brut concernant des inodes
+ */
+typedef struct bloc {
+  char datas[MAX_BYTES_PER_BLOC]; // 1024 octets
+} bloc;
+
+/**
+ * @struct disk
+ * @brief Un disque est un liste d'inodes qui pointent sur des blocs de donnée
+ */
+typedef struct disk {
+  inode inodes[MAX_INODE]; // 10 inodes max
+  bloc blocs[MAX_BLOCS]; // 30 blocs max
+} disk;
+
+// pour 10 inode qui a 30 blocs de chacun 1024 octets, on a 30720 octets, soit
+// 30,7 Ko sur le disque
+```
+
+---
+
+## V. Liste des fonctions principales
+
+### Primitives Système
+- **`int mycreat(char *nom, int mode)`** : Crée un fichier et retourne son inode.
+- **`int myread(int inode, char *buffer, int nombre)`** : Lit n octets depuis l'inode.
+
+### Commandes Shell
+- **`do_ls()`** : Lit le répertoire actuel et affiche les noms et inodes associés.
+- **`do_mkdir(char *nom)`** : Crée un i-node de type répertoire et initialise les entrées . et ..
+
+---
+
+## VI. Répartition des tâches
+
+L'équipe est divisée en groupe pour assurer l'intégration finale.
+
+### 1. SGF & Stockage (Alexis et Youssef)
+- Initialisation et formatage du disque virtuel (inodes à 0).
+- Fonctions de sauvegarde/rechargement du SGF dans le fichier image.
+
+### 2. Primitives & I-nodes (Teddy et Baptiste)
+- Gestion de l'allocation des blocs et des i-nodes.
+- Développement des primitives mycreat, myopen, myread, mywrite.
+
+### 3. Shell & Commandes (Lucas et Alexis)
+- Création de l'interpréteur de commandes (processus fils et exec).
+- Implémentation des commandes ls, mkdir, cat, rm.
+
+### Planning prévisionnel
+
+| Phase | Description | Échéance |
+| :--- | :--- | :--- |
+| **Phase 1** | Analyse des besoins et structures de données | 20 avril 2026 |
+| **Phase 2** | Conception des algorithmes principaux | 2 mai 2026 |
+| **Phase 3** | Développement du SGF et des primitives | Mai 2026 |
+| **Phase 4** | Finalisation du Shell et tests de validation | 28 mai 2026 |
+| **Phase 5** | Soutenance et remise du code source | 29 mai 2026 |
+
+---
+
+## VII. Conclusion
+Ce rapport constitue le socle de développement de notre Mini SGF. En respectant une séparation nette entre le stockage, les primitives et l'interpréteur, nous visons une architecture robuste conforme aux attentes. La prochaine étape sera la validation des algorithmes de lecture/écriture.