Conception d'un système de fichiers

Bonjour,
Pour un intranet d’une asso de mon école, on voudrait mettre en place un système de fichier, une sorte de google drive, implémenté par nos soins. J’ai fait quelques recherches, mais je pense qu’il me manque les mots clés pour décrire ce que je veux étant donné que je n’ai trouvé aucun résultat.

Ce que l’on voudrait c’est une page rassemblant les fichiers rangés dans des dossiers ou non, ça dépend où il a été placé. Ce fichier aurait un nom, un mime, un créateur (l’utilisateur qui l’a envoyé)… On voudrait également, dans un second temps, proposer un système d’historique de modification du fichier.

Le tout tourne sous NodeJS avec Express. Ce que j’ai du mal, c’est d’imaginer comment on va mettre tout ça en place. Il me faut, je pense, une table dans ma base de données pour les fichiers, une pour les dossiers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Fichier :
- nom
- mime
- utilisateur
- chemin
- dossier (par défaut '/')
- dates de création et de modification

Dossier :
- nom
- utilisateur
- chemin
- dossier (par défaut '/')
- dates de création et de modification

Je comptais entasser tous les fichiers dans un dossier storage sur le disque et créer une arborescence avec des faux dossiers qui n’existent pas en vrai.

Est-ce une bonne façon de faire ? On cherche quelque chose qui sera facilement améliorable pour plus tard. Si on veut ajouter notre historique de modifications pour chaque fichier, comment faire ? Une nouvelle table ?

Merci à vous.

Question bête mais… pourquoi ré-inventer la roue ?

Il existe déjà des systèmes auto-hébergés similaires comme ownCloud, NextCloud ou Cozy…

Parce qu’une simple interface Web ça a vite ses limites quand tu joues avec beaucoup de fichiers. Et développer des clients natifs pour chaque plateforme, ça va prendre trèèèès longtemps.

implémenté par nos soins

C’est vraiment impératif ?

Il existe déjà des systèmes auto-hébergés similaires comme ownCloud, NextCloud ou Cozy…

Et il y a également tous les systèmes plus “pro” dits “object storage” comme AWS S3, OpenStack Swift et des tas d’autres.

Parce que le serveur n’aura aucune connexion extérieur et qu’il faut que le service soit intégré à un ensemble d’autre service déjà en place sur le site. On ne cherche pas juste un cloud, c’est une interface permettant plusieurs chose dont un petit cloud très simple.

Je suis également contre ré-inventer la roue mais là on a pas trop le choix j’ai l’impression…

Tu peux installer owncloud sur ton serveur interne, si c’est la connexion avec l’extérieur qui te gêne.

Oui mais ce ne sera pas intégré, en cliquant sur le profil de l’utilisateur, je n’aurais pas accès à ses logs, ses fichiers, ses billets, son emploi du temps… (Tout est implémenté sauf le système de fichier )

À mon avis, si tu as des besoins très spécifiques il vaut mieux que tu utilises un “object storage” déjà existant avec une API cool (S3 ?) et que tu ne réécrive que le frontend avec quelques bouts de scotch pour l’intégration à l’ensemble des autres services déjà en place. C’est toujours beaucoup de boulot mais c’est déjà vachement moins monumental.

Je suis assez d’accord avec motet-a. Si ça répond à tes besoins mieux vaut utiliser l’API de quelque chose de déjà existant (owncloud a une API par exemple, qui te permet de manipuler des fichier sur le serveur sans avoir besoin de l’interface Web par défaut).

Après, peut-être que vous avez envie de vous faire plaisir en développant une solution custom ?

Quitte à ne pas réutiliser une solution à haut niveau qui contient tout le bazar comme owncloud, ce que je comprends tout à fait (personnellement je ne voudrais pas non plus), tu devrais au moins réutiliser des solutions existantes à plus bas niveau je pense.

Par là, je veux dire, pourquoi faire un système avec des faux dossiers ? Sauf si tu as vraiment peur de te faire pirater et pomper toutes les onnées ou si tu as un impératif sécuritaire précis, utilise le système de fichiers natif. Tu te casseras beaucoup moins les dents. Pareil pour le système de versionning: il y a GIT, ou alors un dépôt SVN local, ça fera sûrement l’affaire et les API depuis à peu près n’importe quel langage ne manquent pas.

C’est toujours la même chose quand il faut décider jusqu’à quel niveau on va réutiliser plutôt que faire soi-même ou l’inverse; où se place-t-on entre "je veux un truc qui marche sans me faire ch###, tout de suite, pas cher et qui est joli" et "j’ai envie de m’éclater, d’apprendre des tas de choses très intéressantes, j’ai le temps et je m’en fous si c’est un peu moche ou parfois pas super pratique". Au niveau extrême d’un côté pour notre cas ici on a owncloud, ou encore mieux, un NAS prêt à l’emploi; à l’autre extrême on crée son propre système d’exploitation, voire carrément son propre matériel. En général on pose le curseur en fonction du temps et/ou de l’argent qu’on a ou qu’on veut mettre, de sa motivation et de son niveau technique