Consignes

Projet à réaliser en équipe de 5 étudiants. Les équipes seront tirées au sort et gérées sur le serveur thor/ruby.

Le langage de programmation devra être le C. Vous devez créer un repository SVN ou GIT sur le serveur thor/ruby.

Rapport et démonstration intermédiaires

Une démonstration des fonctionnalités implémentées devra être présentée lors de la 5ème ou 6ème séance (date exacte à confirmer pour chaque groupe). L'encadrant passera une dizaine de minutes avec chaque équipe pour faire un point détaillé sur ce qui marche ou ne marche pas, notamment en faisant tourner les différents programmes de tests.

Un rapport intermédiaire (environ 4 pages) sera envoyé 3 jours avant en PDF par mail à votre encadrant et à Brice Goglin. Il décrira ce qui marche ou ne marche pas, pourquoi, et ce que vous avez prévu de faire pour la suite du projet. Inutile de rappeler le sujet !

Rapport et soutenance de fin de projet

La soutenance finale aura lieu en salle TD8 aux créneaux suivants:

Horaire	Mercredi 11	Vendredi 13
9h00	G1-T1	G3-T5
9h20	G2-T1	G3-T4
9h40	G2-T4	G4-T2
10h00	G1-T3	G3-T3
10h20	G2-T5	G4-T5
10h40	G1-T5	G3-T1
11h00	G1-T2	G3-T2
11h20	G2-T2	G4-T1
11h40	G1-T4	G4-T3
12h00	G2-T3	G4-T4

Elle durera environ 13 minutes suivies d'environ 5 mn de questions, et consistera en une présentation sur vidéoprojecteur et une démonstration. Vérifiez avant de venir que vous savez utiliser un vidéoprojecteur avec votre ordinateur, et allumez votre ordinateur avant d'entrer dans la salle.

Un rapport d'environ 8 pages devra être rendu avant lundi 09 à 23h59 pour les groupes G1, G2 et G4, mardi 10 à 23h59 pour G3, au format PDF par mail à votre encadrant et à Brice Goglin. Le rapport décrira ce qui a été implémenté, comment et pourquoi. Il sera accompagné d'une archive tar.gz (pas de .rar!) contenant tout le code source et un minimum de documentation permettant de compiler et tester le projet.

Les rapports et soutenance devront notamment expliquer comment vos tests montrent la validité du comportement de votre bibliothèque et indiquer les différents coûts que vous avez mesurés (voir la partie premiers objectifs ci-dessous). Inutile d'écrire des pages pour rappeler le sujet, il faudra se concentrer sur les choses utiles et prêtant à discussion (performance, complexité, modification de l'interface de programmation, ...).

Evaluation

A partir des rapports (intermédiaire et final), de la démo à mi-parcours et de la soutenance finale, on jugera:

• Est-ce que le code compile ? (sans warning)
• Est-ce qu'il marche et quels programmes de test nous le prouvent?
• Quelle est la complexité des différentes fonctions, est-ce que le code marche vite, et quels programmes de test nous le prouvent?
• Quelles fonctionnalités sont supportées?
• Comment vous expliquez le fonctionnement de tout ceci, ses inconvénients, ce qui pourrait être amélioré?

On veut développer un système de fichiers permettant d'appliquer des tags à des fichiers, par exemple des photos (ou de la musique). Une photo pourra par exemple avoir les tags "paysage" et "nuit".

Les photos considérées sont situées dans un seul répertoire sans sous-répertoire. Avant et après utilisation, la base de données est stockée dans un fichier spécial dont le format est le suivant :

tag appliqué à tous les fichiers
[filename1]
tag1 appliqué au fichier filename1
# ligne ignorée car commence par '#' ou vide
tag2 appliqué au fichier filename1
[filename2]
tag3 appliqué au fichier filename2
...

Les fichiers sans aucun tag n'apparaissent pas du tout dans ce fichier.

Le nouveau système de fichiers développé dans le projet crée un répertoire virtuel contenant les mêmes photos, et également des répertoires virtuels pour décrire les tags appliqués à chaque photo. Le répertoire virtuel foo/bar/ contiendra ainsi les photos qui ont les tags foo et bar. Il contient également des sous-répertoires virtuels correspondant à chaque tag qu'une de ces photos pourrait également avoir.

Par exemple, avec ces photos originales :

$ ls /home/login/Photos
a.jpg
b.jpg

et cette base de données :

$ cat /home/login/Photos/.tags
[a.jpg]
foo
bar
[b.jpg]
foo

Si votre programme s'appelle tagfs, on montera le système de fichiers virtuel ainsi :

$ mkdir /home/login/Photos-avec-tags
$ tagfs /home/login/Photos /home/login/Photos-avec-tags
$ ls /home/login/Photos-avec-tags
a.jpg
b.jpg
foo/
bar/
$ ls /home/login/Photos-avec-tags/foo/
a.jpg
b.jpg
bar/
$ ls /home/login/Photos-avec-tags/foo/bar/
a.jpg
$ ls /home/login/Photos-avec-tags/bar/
a.jpg
foo/
$ ls /home/login/Photos-avec-tags/bar/foo/
a.jpg
$ ls /home/login/Photos-avec-tags/coin/
ls: cannot access 'coin': No such file or directory

Au démontage de /home/login/Photos-avec-tags/, la base de données éventuellement modifiée est sauvegardée dans le fichier /home/login/Photos/.tags (après avoir fait un backup de l'ancienne version).

$ fusermount -u /home/login/Photos-avec-tags

Pour ajouter un tag "baz" à la photo a.jpg :

$ ln a.jpg baz/a.jpg

Tagguer un fichier autrement n'est pas autorisé.

Pour enlever le tag "foo" :

$ rm foo/a.jpg

Remplacer le tag "foo" par "baz" :

$ mv foo/a.jpg baz/a.jpg

Ces trois opérations de modification ne sont autorisées que dans les répertoires de 1er niveau. Elles sont interdites dans le répertoire racine ou dans les sous-sous-répertoires (voir les extensions plus bas).

Pour créer un tag:

$ mkdir montag/
$ ln a.jpg montag/a.jpg

Pour supprimer un tag inutilisé:

$ rm montag/a.jpg
$ rmdir montag

On commencera par utiliser FUSE sous Linux. Ca nécessite d'avoir l'en-tête fuse/fuse.h (qui vient avec le paquet libfuse-dev sous Debian/Ubuntu), et d'avoir les droits en lecture/écriture sur le fichier /dev/fuse.

On pourra se baser sur l'exercice 1 du TD4 (sujet et fichiers source).

Toute l'implémentation devra se faire avec une complexité raisonnable :

• Pas de multiples parsing du même chemin de répertoire, voire mieux cacher le résultat des parsing précédents.
• La recherche des photos selon certains tags doit être au maximum en temps linéaire en nombre total de photos.
• La recherche des tags appliqués à une photo particulière doit être en temps linéaire en le nombre de ces tags au maximum.

Ceci devra être illustré en montrant le cout des opérations de base (ls, ln, rm, mv selon les nombres de fichiers totaux et concernés, et selon le nombre de tags totaux et concernés).

Des tests de fonctionnement et de performance sont fournis ici.
Il est vivement conseillé d'ajouter d'autres tests pour vérifier que vos extensions fonctionnent.

Si vous modifiez la sémantique du système de fichiers, il faudra adapter les tests ci-dessus.

• Relâcher les contraintes de la sémantique de modification des tags :
  Autoriser l'ajout de plusieurs tags d'un coup (en gérant les tags éventuellement déjà appliqués) :

  $ ln foo/bar/a.jpg baz/baz2/bar/a.jpg
   

  Eventuellement étendre la sémantique pour modifier ou supprimer plusieurs tags?


• Créer et supprimer les tags automatiquement à la volée quand ils sont utilisés la première ou ne sont plus utilisés (plus besoin de faire mkdir ou rmdir explicitement).


• Supporter les regexp dans les noms de sous-répertoires :
  Le sous-répertoire regexp1/regexp2/regexp3/ contiendrait les photos dont les tags matchent chacunes des 3 regexps.


• Comment consulter les tags d'un fichier sans empêcher de lire son contenu normal?


• Supporter l'appel-système poll pour detecter ajout/suppression de tags sur un fichier.


• Autoriser les photos originales à être réparties dans différents sous-répertoires. Comment distinguer les vrais sous-répertoires des répertoires virtuels de filtrage?


• Vérifier que la base de données matche les photos originales au montage et détecter l'ajout de photos à chaud, ou leur renommage. De plus, comment gérer la suppression d'une photo et éventuellement une future annulation de cette suppression?


• Ajouter un moyen de sauver la base de données actuelles sans démonter pour examiner son contenu à chaud.


• Supporter les accès concurrents. On testera avec plusieurs processus tagguant/détagguant des tonnes de fichiers simultanément.
  Notez qu'on peut forcer la sérialisation des accès à votre système de fichiers en passant l'option -s au programme de montage.


• Gérez des tags basés sur le contenu des vraies fichiers de photo, par exemples des informations EXIF, etc.


• TRÈS DIFFICILE : développer un vrai système de fichiers dans le noyau Linux au lieu d'utiliser FUSE.

• Pour éviter de réimplémenter vous même des listes et de passer des heures à les débugguer, regarder les Queue BSD (un peu obscur au premier abord mais très efficace).


• Pour les tables de hachages, voir uthash.