idée gestionnaire de fichiers + base de donnée

Programmation
#1

Salut à tous.
J’ai eu une idée d’un gestionnaire de fichiers couplé avec une base de donnée sql.

Son fonctionnement en résumé:

  1. avoir une base de donnée, avec des catégories/tables/champs
  2. renseigner les fichiers dans la base de données à l’endroit voulu
  3. afficher/lister/trier les fichiers
  4. remplir les colonnes supplémentaire utile si besoin
  5. menu clique droite

En détails:
Pour le point un, on aura une base de données.
Il y aura plusieurs tables/champs dans cet base de données, ce qui permettra de catégorisé les données: qui appartient à qui, les détails des fichiers droits/titre/date création,modification/type/taille/qualité/rate/etc selon les types (on ajoutera les détails nécessaire voulu).

Pour le point deux, on aura un système d’ajout de fichier, une fenêtre séparer en deux colonnes/parties:

  • à gauche une partie, qui permet de lister les fichiers comme dans les gestionnaire de fichier actuel
  • à droite une partie, qui permet de lister les fichiers comme dans les gestionnaire de fichiers actuel mais pas les fichiers du système, mais bien les fichiers du nouveau gestionnaire de fichier en fonction de la base de données déjà trier
    Et donc, on pourra de la partie gauche, déplacé un fichier, dans la partie droite dans le lieux voulu, ce qui permettra de faire reconnaitre le fichier dans le nouveau gestionnaire de fichiers (et donc dans la base de donnée).
    (On peut aussi automatiser cet tâche.)

Pour le point trois, on peut lister les fichiers comme dans les gestionnaire de fichiers actuel, il y aura aussi un système de triage en fonction des colonnes présents (possibilité de lister selon plusieurs détails par ordre et pas par un seul détail comme les gestionnaire de fichier actuel).

Pour le point quatre, on aura la même fenêtre du point trois. Avec une touche/menu, on pourrait passer en mode édite, et les colonnes seront modifiable en temps réel, les colonnes: titre, type, taille, date, qualité, rate etc selon le style de fichier et ses colonnes disponible.

Pour le point cinq, comme dans chaque gestionnaire de fichiers, le bon vieux menu clique droit, il le serait aussi.
Et sera personnalisable: lancer x commande, lancer via: xxx + optionnellement une liste d’autres options ouvrir avec x,y,z

Et quelques autres fonctionnalité en deuxième priorité:

  • raccourcie rapide
  • multiple onglet
  • barre de statue: qui affiche les détails des fichiers, la barre sera par défaut masqué, mais sera affichable via une option, sa sera utile en cas d’affichage mode compacte/listage sans détails/colonnes.

Sa sera bien utile quand on possède beaucoup de fichiers et de plusieurs type qu’on doit gérer/trier.

Une telle idée m’est arrivé à cause d’un soucis réel: à cause des limitations disque dur, je peux pas garder les mêmes type de fichier dans un seul dossier, si je dois y parvenir en ce moment, le seul moyen serait de faire des liens symboliques des fichiers voulu et de les rassembler dans un dossier dédiés, mais pas pratique.

Avec ma méthode, on trie tous dans la base de données et on affiche ce triage sans limites dans un seul dossier, que l’on ait 1 disque dur de 1000 gb ou 10 disque dur de 1000 gb chacun avec les données mélangé.

Et sinon, vous en pensez quoi de ce système ?

édite: hier en fermant mon ordinateur après ce sujet, j’ai eu l’idée flash de “bibliothèque”, je me demandes si mon gestionnaire de fichiers spéciale pourrait être nommé comme quelque chose de bibliothèque (de fichiers).

#2

[quote=“kripteks”]Salut à tous.
J’ai eu une idée d’un gestionnaire de fichiers couplé avec une base de donnée sql.

Son fonctionnement en résumé:

  1. avoir une base de donnée, avec des catégories/tables/champs
  2. renseigner les fichiers dans la base de données à l’endroit voulu
  3. afficher/lister/trier les fichiers
  4. remplir les colonnes supplémentaire utile si besoin
  5. menu clique droite
    [/quote]

1.- quelle gestionnaire de base de donnée ? mysql ?sqlite autre ? attention aux droit…
2.- pas très claire bon disons quand tu les manipule que cela soie fait automatiquement??
3.- qu’elle interface ? console, console avec une lib, sous x qt autre ?
4.- dépant de 3.- mai sa va de soit je dirait
5.-configurable plutôt :slightly_smiling:

les mettre dans la base de données sa a des avantages,
1.-s’il son modifier ou pas. donc un très bon suivis ce qui manque a linux .
2.-mai attention aux droit des fichier! pour mettre a jour la base de donnée tu donne les droit qu’a l’utilisateur de base. ce qui veux dire de la redondance si plusieurs utilisateur manipule un/plusieurs répertoire ta base va devenir assez grande. donc sqlite est a mon avis pas suffisant sachant que les disque son de taille de 4To … de quoi contenir suffisamment de fichier pour fait craquer une base de donnée sans compter les montage de type lvm/raid … le souci va clairement être la limite de la base de donnée…

3.- Dans ta base tu fait tout ce que tu veux. perso j’avais commencer un projet ,a peux près similaire, le but était juste d’avoir un suivis des fichier. sa rjoints donc ton projet. coder en c++
j’ai abandonner car le boulot est quand même imposant mine de rien et tout passait par des api C ce qui devien casse c** quand on cod een c++ a ce taper des wrapper… pour moi un bon gestionnaire de fichier doit etre capable de tourner en console et sous X par exemple avec ncuses et qt. car sur un serveur il n’y a pas de X …

[quote]
Pour le point deux, on aura un système d’ajout de fichier, une fenêtre séparer en deux colonnes/parties:

  • à gauche une partie, qui permet de lister les fichiers comme dans les gestionnaire de fichier actuel
  • à droite une partie, qui permet de lister les fichiers comme dans les gestionnaire de fichiers actuel mais pas les fichiers du système, mais bien les fichiers du nouveau gestionnaire de fichier en fonction de la base de données déjà trier
    Et donc, on pourra de la partie gauche, déplacé un fichier, dans la partie droite dans le lieux voulu, ce qui permettra de faire reconnaitre le fichier dans le nouveau gestionnaire de fichiers (et donc dans la base de donnée).
    (On peut aussi automatiser cet tâche.)

Pour le point trois, on peut lister les fichiers comme dans les gestionnaire de fichiers actuel, il y aura aussi un système de triage en fonction des colonnes présents (possibilité de lister selon plusieurs détails par ordre et pas par un seul détail comme les gestionnaire de fichier actuel).

Pour le point quatre, on aura la même fenêtre du point trois. Avec une touche/menu, on pourrait passer en mode édite, et les colonnes seront modifiable en temps réel, les colonnes: titre, type, taille, date, qualité, rate etc selon le style de fichier et ses colonnes disponible.

Pour le point cinq, comme dans chaque gestionnaire de fichiers, le bon vieux menu clique droit, il le serait aussi.
Et sera personnalisable: lancer x commande, lancer via: xxx + optionnellement une liste d’autres options ouvrir avec x,y,z

Et quelques autres fonctionnalité en deuxième priorité:

  • raccourcie rapide
  • multiple onglet
  • barre de statue: qui affiche les détails des fichiers, la barre sera par défaut masqué, mais sera affichable via une option, sa sera utile en cas d’affichage mode compacte/listage sans détails/colonnes.

Sa sera bien utile quand on possède beaucoup de fichiers et de plusieurs type qu’on doit gérer/trier.

Une telle idée m’est arrivé à cause d’un soucis réel: à cause des limitations disque dur, je peux pas garder les mêmes type de fichier dans un seul dossier, si je dois y parvenir en ce moment, le seul moyen serait de faire des liens symboliques des fichiers voulu et de les rassembler dans un dossier dédiés, mais pas pratique.

Avec ma méthode, on trie tous dans la base de données et on affiche ce triage sans limites dans un seul dossier, que l’on ait 1 disque dur de 1000 gb ou 10 disque dur de 1000 gb chacun avec les données mélangé.

Et sinon, vous en pensez quoi de ce système ?

édite: hier en fermant mon ordinateur après ce sujet, j’ai eu l’idée flash de “bibliothèque”, je me demandes si mon gestionnaire de fichiers spéciale pourrait être nommé comme quelque chose de bibliothèque (de fichiers).[/quote]

tu dis que tu peux pas mettre les meme type de fichier dans un dossier, la je compremd pas ton souci.
en très très gros, 2 chose son interdite: les meme nom de fichier/dossier, mai si tu donne le meme nom comment fera tu la différence ??
les caractère interdit dans les nom de fichier!

sinon tu peux les classer par type , txt, cpp etc donc la quelque chose cloche :017

tu va un peux vite en besogne. si ta base est corrompue,plus a jour suite a une maintenance du disque … sa doit donc être syncro avec le disque. c’est donc lourd pour le systeme.
pour te donnée une idée fait simplement un :

find / | wc -l

337809 fichier a indexer

c’est du taff mine de rien,si si :slightly_smiling:

#3

Pour le choix de la base de donnée je sais pas, j’ai pas voulu me précipité dans le choix, sans allé en profondeur sur le sujet.
En fonction des besoins, je ferais le meilleur choix possible et bien entendu le plus libre possible.

Sinon pour éclaircir un peu.
Le gestionnaire de fichiers que je désires est en fait de faire une bibliothèque de nos fichiers.
J’ai eu l’idée de le nommé bibliothèque que après l’ouverture du sujet (et fermeture de mon ordinateur :smiley:).

Mon bibliothèque de fichiers, index ce dont on choisit et non pas tous les fichiers du système.
Ce qui permet d’indexer que l’essentiel, pour mon cas, la priorité est d’indexer les fichiers global d’utilisateur (documents, multimedia, projets, etc) et pas les fichiers du système ou les fichiers pas intéressent.

Au début je voulais le faire graphiquement (gtk(mm) ou autres), mais après j’ai pensé à mc (midnight commender) qui fonctionne en console, moins léger dans ma pensé et peut-être aussi utiliser avec la souris, mais j’ai pas trouvé très attirant, surtout niveau docu c’est pas super, donc je me suis retourner vers gtk ou autres mais pas décider encore lequel.
Si je le fais c’est en c++ en tout cas.

Pour ce qui est de:

En fait par même type de fichier, je parlais des fichiers semblable avec tout simplement une même extension.
Tu as confondu “même type” avec “même nom”.

Disons que j’ai 100 gb de vidéo d’une série et j’ai 2 disque dur de 80 gb.
Si j’oragnises mes dossiers comme “dossier/sous-dossier/sous-sous dossiers”:
multimédia/série/xxx/saison 1/
multimédia/série/xxx/saison x/
multimédia/série/xxx/saison 20/
le tous fait 70 gb, et disons j’ai mes autres fichiers:
documents/xx
xx/xx
ceux-ci font 10 gb, et avec mon dossier multimédia, j’ai au total 80 gb et mon disque dur est devenu rempli.
Si je veux rajouter des nouvelles saisons:
multimédia/série/xxx/saison 21
multimédia/série/xxx/saison xx
multimédia/série/xxx/saison 30
le tous 30 gb, j’ai pas d’espace sur le disque dur 1, donc je dois prendre un deuxième.
Mais celui-ci est vide, donc je dois re créé multimedia/série/xxx/, mais les anciens saison seront pas disponible sur ce dossier, car ils sont sur le disque dur 1, et je peux pas les rassembler en les copiant car pas d’espace disponible, du coup je suis obliger de faire des liens symbolique, mais pas très efficace.

Sinon, comme j’ai dis:
Le but est d’indexer les fichiers voulu et de les manipuler facilement avec le plus options possible si nécessaire.
L’indexation peut être fait manuelement ou automatiquement graphiquement, sa sera bien user friendly, simple et efficace.

Je vais vous donné un exemple de dossier dans une base de donnée:
“id” “xxx”
“lieu_reel” "/media/disquedur5/multimedia/série/xxx/saison 3"
“nom” "saison 3"
“lieu_nonreel” “multimedia/série/xxx/saison 3"
“taile” “xxx”
“droits” xxx”
“date_modification” “xxx”
“date_création” “xxx”
“description” “”
“etc” “etc”
“etc” “etc”

Et disons que j’ai un autre disque dur 2 avec les saison 4 et 5, un autre disque dur 3 qui contient les saison 6 à 10.
On les index (graphiquement ou non, automatiquement ou non ect) mais bien entendu dans la base de donnée en arrière plan, dans "/media/disquedur5/multimedia/série/xxx/ saison 3 du disque dur 1, saison 4 et 5 du disque dur 2, 6 à 10 du disque dur 3.

Et donc dans mon programme graphiquement, j’aurais:
Le dossier multimedia, dedans série, dedans xxx, dedans saison 3,4,jusqu’à 10.

Si une manipulation de déplacage sera fait, il sera fait directement au niveau base de donnée: changement simple du nom de “lieu_nonreel” “a” vers “lieu_nonreel” “b” et voila les lieux sont déplacer, mais le fichier réel reste au même endroit.
Une suppression de donnée, sera fait simplement dans la base de donnée, suppression de id et le voila plus parmis nous mais le fichier réel n’est pas affecté donc pas supprimé.
Mais, on pourra aussi affecté les changements réel: renommer/suppression/déplacement avec une méthode prévu pour.

En plus de cela, on pourrait aussi rajouté, des colonnes dans la base de donnée, toujours dans notre exemple “xxx saison y”: prenons la saison 5: dans la base de donnée: “description” “La saison 5 se déroule bla bla bla”.
Dans notre bibliothèque de fichiers graphiquement, on peu activer les options de triage en cochant: afficher les description dans une colonne “description” (qui sera afficher comme dans les détails (taile/type/etc) dans les gestionnaire de fichiers actuel).

Dans les saisons de notre exemple, il y a bien des fichiers vidéos à l’intérieur, après les avoir indexé etc, disons qu’on aurait des colonnes supplémentaire: taille, format, piste, rate vidéo, ratio, rate audio, type, etc.
On pourrait encore faire le triage dans notre bibliothèque graphique (pour l’affichage), trier d’abord par le numéro de piste, puis qualité vidéo, puis qualité son, puis x puis y, aussi cocher les détails que l’on veut afficher etc.

Pour ce qui est de plusieurs utilisateur et des droits, on trouvera surement un bon truc intelligent.

Pour ce qui est des caractères dans les nom de fichier, on pourrait aussi enlever cet interdiction.
Comme dit plus haut, les modifications sont fait seulement sur la base de donnée et pas sur le fichier réel.
À part, si on précise qu’on affecte le fichier réel mais dans ce cas l’interdiction des caractère reviendra et d’autres précaution sera pris aussi en compte bien entendu.

Pour ce qui est de garder à jours avec les fichiers réel, l’utilisateur devrait faire attention.
Un système intelligent pourra être fait, qui permettra lors d’un changement réel, de faire le nécessaire pour garder à jours les emplacements, donc une collaboration système automatisé + utilisateur sera nécessaire.

Une fois les données dans la base de donnée, la manipulation na pas de limite.

Cet bibliothèque de fichiers peut aussi être fait pour un gestionnaire de fichiers avec une base de donnée qui doit donc traiter tous les fichiers mais bonne chance à celui qui le fera, comme tu dis, sa sera pas facile pour ce dernier.

#4

Je pense qu’il y a un certains nombre de choses dans ce que tu décris qui existe déjà.

Premièrement quand tu décris les problèmes de places. Il y a une solution très vielle à ça c’est LVM. Plus récent, btrfs permet aussi de résoudre le problème. Il est aussi possible d’utiliser unionfs ou aufs.

Les entrées de la base de données que tu décris sont des inodes et tu peut utiliser les attributs étendus pour ajouter ce que tu veux (fr.wikipedia.org/wiki/Attributs_%C3%A9tendus).

Pour la partie déplacement et suppression de fichier tu décris le linkage des fichiers. C’est le fonctionnement de base de tout les dérivés d’unix tant que l’on reste sur une même partition (et avec lvm ou btrfs c’est tout à fait faisable).

Pour ce qui est des caractères dans les noms de fichiers, la seule limitation de la plupart des systèmes de fichiers est le caractère null (qui a pour valeur 0). C’est pas une grosse limitation à mon avis.

Pour un petit topos sur les inodes (fr.wikipedia.org/wiki/Inode) :
Les fichiers sous unix sont géré par des inodes. Celles-ci contiennent toutes les informations sur le fichiers (dates, taille, etc) et les information sur comment retrouver le contenu du fichier. Un chemin de fichier représente un inode, mais un inode peut représenter plusieurs chemin. C’est ce que l’on appel le lien en dur (jard link). Ça fonctionne tant que l’on reste sur une même partition. Le renommage, le déplacement et la suppression de fichier utilise cette fonctionnalité (c’est pour ça que déplacer un fichier est aussi rapide).

Je ne veux pas dire que tes idées sont mauvaises au contraire, juste que ce qu’il manque c’est surtout une manière d’exposer ces fonctionnalités à l’utilisateur.

#5

Salut.
Merci pour tes explications très intérressent.

Il y a une chose à savoir: au début j’ai expliquée mon idée comme un gestionnaire de fichiers mais en réalité quand on y pense et modifie un peu sa donne une bibliothéque de fichiers.

Le but était de manipulé les fichiers dans cet bibliothéque sans affecté réelement les fichiers réel (du moins sans l’avoir demandé explicitement), dans le but de pouvoir les trier/organiser le plus possible.

Maintenant, ton explication est basée sur les fichiers réel, ce qui change la donne.
Sa semble intérressent, sa revient au même qu’à mon idée, à deux choses: tous les opérations seront réel et durable.
On aurait plus le besoin de base de donnée vu que c’est déjà comme une base de donnée déjà présent.

D’ailleurs sa ma permis d’avoir une idée, si j’ai bien compris.
Les fichiers ont tous un chiffre (d’identifiant) qui est l’inode et quelques info supplémentaire qui sont les attribues étendu.
Les système de fichiers qui veulent suivre la règle de posix (comme ext4 j’imagines), on par défaut des attribues étendu sur les fichiers (date, droits, taille, etc), je comprend bien mieux l’existance de posix.

Disons que je voudrais ajouter des attribues étendues et que je le fais.
Ceux-ci seront sauvegarder mais quelles sont les cas où je pourrais perdre ces attribues étendues ?

Sinon, on pourrait faire 3 cas:
1- gestionnaire de fichiers avec les inodes et attribues étendue, bas niveau.
2- bibliothèque de fichiers avec la base de donnée, haut niveau.
3- on pourrait même couplé inode, attribues étendu et base de donnée, sa pourra faire un truc vraiment puissant.

Donc là maintenant si je devrais faire quelques chose, je ferais surement le 3ème point (Mais je manques d’information sur les inodes et attribues, donc je peux pas certifié mon choix final, je vais étudier en détails).

#6

Non c’est le numéro d’inode.

Non ce que tu cite ne sont pas des attributs étendus.

Même chose que les attributs normal donc problème sur le disque dur (crash disque et autre).

Qu’est ce que t’apporte une base de données relationnelle ?

#7

Ah oui je me suis trompé à l’écriture de l’attribue normal et étendu.

Pour la base de donnée.
Je me disais qu’il serait peut-être plus judicieux d’utiliser une base de donnée pour les a.é, et être en synchrone via le numéro unique du fichier réel.

Car: je me disais que peut-être ces a.é ont des limites et inconvénients.

Par exemple, si j’ajoutes des a.é aux fichiers réel, puis si je partages ces fichiers, les a.é seront publique et cela peut-être un peu angoissent (pour les attribues personnel/intime/fait n’importe comment et donc ridiculisant).

Et je sais pas s’il y a des limitations dans les contenu des a.é.

J’arrives pas à trouver des informations un peu détaillé sur le sujet à part l’explication global des a.é.
Je vais y chercher plus profond.

#8

Ça dépend de la manière dont tu partage. Je doute que CIFS le gère. Pour NFS je sais pas.
Mais quoi qu’il en soit attr(5) dit :

La taille mais c’est paramétrable et c’est utilisable uniquement sur les fichiers régulier et les dossiers.

[quote=“kripteks”]J’arrives pas à trouver des informations un peu détaillé sur le sujet à part l’explication global des a.é.
Je vais y chercher plus profond.[/quote]
Cherche avec xattr comme mot clef (tu peut déjà lire attr(5)).