Forum général.général Recollage "virtuel" de fichiers

Posté par  .
Étiquettes : aucune
0
6
juin
2006
Bonjour,

Voilà, je me questionnais à propos d'une fonctionnalité possible dans la gestion des fichiers.
Supposons que j'ai 1 fichier (vidéo par exemples, car cela s'y prête mieux)
-fichier.avi de 7 Go
Pour des raisons quelconque, je décide de couper ce fichier en morceaux (3+3+1 Go)
-fichier1.avi (3 Go)
-fichier2.avi (3 Go)
-fichier3.avi (1 Go)
à l'aide de split par exemple.

Pour regrouper ces fichiers, on utilise cat et on se retrouve avec un fichier final.
Moi, je voulais savoir s'il n'y avait pas moyen de créer un fichier virtuel (une sorte de lien ?) fichier.avi qui serait vu en fait comme le regroupement de ces 3 fichiers en un seul fichier (mais qui ne prendrait pas la taille des trois fichiers évidemment). Ainsi, on conserverait des petits morceaux de fichiers, mais on pourrait les considérer comme un gros fichier à partir d'un fichier virtuel.
Bon bien sûr, vous allez me dire que pour les vidéos il suffit de les enchaîner dans mplayer, on voit quasiment pas la transition, mais cela peut s'appliquer avec d'autres types de fichiers ;)

Voilà, merci de vos réponses :)
  • # dans le Hurd, peut-être ?

    Posté par  . Évalué à 1.

    Il y a peut-être moyen d'implémenter dans un module du noyau un "système de fichiers" qui puisse réaliser ce genre de choses... Je ne vois pas trop cependant comment intégrer ça de façon très propre.

    Si tu tiens à faire ce genre de choses, il faudrait peut-être aller voir du côté du Hurd.

    Au fait, je ne suis pas certain que beaucoup de players soient capables de lire un fichier .avi sans en-tête !
  • # un pipe?

    Posté par  (site web personnel) . Évalué à 5.

    Si ton programme peut lire sur son entrée standard, alors un pipe "|" suffit:
    $ cat fichier1.avi fichier2.avi fichier3.avi | mplayer -
    (pour beaucoup de programmes, le nom de fichier "-" représente l'entrée standard)

    Sinon tu dois pouvoir t'en sortir avec un pipe nommé (man mkfifo).
    Même fonctionnement, et aussi avec cat:
    $ mkfifo tout.avi
    $ cat fichier1.avi fichier2.avi fichier3.avi > tout.avi &
    $ mplayer tout.avi
    (quand mplayer se termine, le cat en tache de fond se termine aussi.)
    $ rm tout.avi

    La différence avec ta méthode est que "tout.avi" ne prend pas d'espace disque. C'est un fichier spécial qui a le même fonctionnement qu'un "|". Et comme pour le "|", ça ne marche qu'une fois...

    S'il existe une solution pour associer définitivement le pipe "tout.avi" avec les fichiers qui doivent en sortir, je ne la connais pas...
  • # réinventer la roue

    Posté par  (site web personnel) . Évalué à 1.

    Euh, tu sais que c'est ce que fait le système de fichier ? Il fractionne ton fichier en petits bouts sur le disque.
    Bref j'ai l'impression que tu veux réinventer la roue à un niveau d'abstraction supérieur :)
  • # Abstraction

    Posté par  . Évalué à 1.

    Merci pour les réponses
    En fait, si j'ai bien compris, on utilise des petites astuces de pipe et tout et tout pour le faire. Je pensais à un truc plus bas niveau effectivement que ça (genre au niveau du système de fichier)...
    Pourquoi le Hurd serait il plus enclin à faire ça ??
    • [^] # Re: Abstraction

      Posté par  . Évalué à 2.

      D'après ce que j'ai pu lire sur le sujet, une des particularités du Hurd est de généraliser la notion de système de fichiers et d'en déporter la gestion dans l'espace utilisateur. C'est ce que les hurdistes appellent les translators ou traducteurs.

      ( voir par exemple http://wiki.hurdfr.org/index.php/Le_Hurd )
      • [^] # Re: Abstraction

        Posté par  (site web personnel) . Évalué à 4.

        On peux avoir le même genre de fonctionnalités avec fuse (même si ce n'est pas la panacée).
        Y'a même un binding en python, on doit pouvoir developper ca a peu de frais
        http://fuse.sourceforge.net/wiki/index.php/FusePython

        Pour info, je m'etais posé ce genre de questions il y a quelques temps
        http://linuxfr.org/~jjl/17858.html
      • [^] # Re: Abstraction

        Posté par  . Évalué à 1.

        D'ailleurs, les solutions des tubes sont pas mal. Mais le problème est qu'on ne peut pas parcourir la vidéo par exemple avec mplayer (il considère les données vidéos comme brutes, ce qui est normal ;))
        Peut être qu'avec une solution plus bas niveau, cela marcherait..

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.