Cela peut être utile pour la gestion de révision évidemment (code source, documentation, fichiers personnels, etc.), mais aussi la détection d'intrusions, la prévention de perte de données et également pour répondre aux besoins légaux de rétention de données.
Certains points de ext3cow sont intéressants :
- il ne pollue pas les répertoires de copies de fichiers nommés (généralement suffixés) par un identifiant de version ;
- il consomme peu en terme de stockage (5 à 15 % de metadata) et performance (lors des snapshots) ;
- il est modulaire et ne nécessite pas de changements du noyau ou des interfaces VFS.
Le concept de système de fichiers versionnés n'est pas nouveau (euphémisme), mais ext3cow diffère des autres par de nombreux avantages (voir synthèse en PDF), dont le fait qu'il référence des versions à n'importe quelle date dans le temps et pas par des identifiants de version (qu'il faut évidemment connaître). ext3cow est bien entendu incompatible avec ext2/ext3, mais il devrait apparaître des outils de conversion triviaux rapidement car il y a regain d'intérêt dû à une brève sur Slashdot. Exemple rapide :
[user@machine] echo "This is the original foo.txt" > foo.txt
[user@machine] snapshot
Snapshot on . 1057845484
[user@machine] echo "This is the new foo.txt." > foo.txt
[user@machine] cat foo@1057845484
This is the original foo.txt.
[user@machine] cat foo
This is the new foo.txt.
[user@machine] snapshot /usr/bin
Snapshot on /usr/bin 1057866367
[user@machine] ln -s /usr/bin@1057866367 /usr/bin.preinstall
[user@machine] /usr/bin.preinstall/gcc
Aller plus loin
- The ext3cow File System (26 clics)
- Ext3cow: A Time-Shifting File System for Regulatory Compliance (PDF, 225 Ko) (7 clics)
- La FAQ sur ext3cow (4 clics)
- Brève /. sur ext3cow (240 commentaires) (4 clics)
- Mailing-list ext3cow-devel (2 clics)
- Journal précédent (8 clics)
# intéressant
Posté par B16F4RV4RD1N . Évalué à 8.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: intéressant
Posté par toctoc1 . Évalué à 3.
D'ailleurs à ce sujet, je trouve vraiment classe que la communauté du libre soit aussi "dans le match" à ce niveau là.
Je n'y vois que des avantages au boulot, par exemple, ou je passe pas mal de temps à corriger des versions de fichiers...
je vais suivre avec attention ce développement, en tout cas.
[^] # Re: intéressant
Posté par B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: intéressant
Posté par - - . Évalué à 7.
Time Machine d'apple n'est qu'un programme de backup et une élégante interface pour parcourir ce backup
le backup est stocké dans un dossier, avec des sous dossiers pour les jours de sauvegardes
ce n'est PAS ZFS
ce ne sont PAS des meta-données (que gère déjà HFS+)
ou des "forks" de fichiers (que gère HFS+)
ce n'est PAS lié au système de fichier (léopard n'abandonne pas hfs+ )
ce n'est PAS du snapshot.
--
cela dit , oui ZFS sera intégré à leopard. les beta permettaient déjà de créer des partitions ZFS avec toutes leurs possibilités (sauf en faire une partition de boot, le firmware des mac ne sachant pas booter dessus pour le moment).
[^] # Re: intéressant
Posté par Denis Bodor (site web personnel) . Évalué à 3.
http://arstechnica.com/staff/fatbits.ars/2006/8/15/4995
[^] # Re: intéressant
Posté par gpe . Évalué à 5.
[^] # Re: intéressant
Posté par toctoc1 . Évalué à 2.
http://fr.wikipedia.org/wiki/Zettabyte_File_System
"Sun a indiqué qu'ils comptaient porter le produit sur Linux. Actuellement, il n'y a aucun projet pour HP-UX, ou même AIX. Mais depuis que ZFS est en open source, le portage peut être effectué sans la participation de Sun. Matt Dillon du projet DragonFlyBSD a d'ores et déjà prévu de porter ZFS pour la version 1.5 de leur OS.
ZFS est désormais supporté par Leopard Mac OS X, ainsi que sur la dernière version de Tiger (10.4.9)."
[^] # Re: intéressant
Posté par Mildred (site web personnel) . Évalué à 4.
Certaines personnes peuvent trouver que l'utilisation de nos bonnes vieilles partitions est excellante, mais je pense plutôt que cela rend difficile toute opération de redimentionnement. Du coup lorsque j'ai acheté un disque de 200GB, j'ai fait une multitude de partitions de 10GB qui ne sont finalement pas pratiques.
Et si c'est compatible Mac OS X, que du bonheur.
Concernant l machine a remonter le temps, je trouvais cela uen très bonne idée de la part d'Apple. Nous on l'a (avec les gestionnaires de révisions comme bzr notament qui ne nécessient pas de créer un repository, je le conseille d'ailleurs, ou maintenant avec ext3cow) mais ce n'est pas intégré dans l'interface graphique et pas acessible aux utilisateurs de base. Sans forcémennt faire une interface 3D comme dans Mac OS, je pense que cela peut être intéressant d'intégrer cela.
Et il y a aussi le fait que je pense que la machine a remonter le temps prendra des snapshots automatiquement aussi. Même si on doit pouvoir en faire soi même aussi, je pense.
[^] # Re: intéressant
Posté par B16F4RV4RD1N . Évalué à 4.
http://kerneltrap.org/node/8066
Par contre c'est en développement pour fuse, et l'argumentaire ici est intéressant également :
http://zfs-on-fuse.blogspot.com/2007/04/zfs-in-linux-kernel.(...)
moi je rêve d'un système de fichier pleinement compatible entre tous les unix (linux, *bsd, solaris, mac os x).
Qui a dit vfat ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: intéressant
Posté par adam0509 . Évalué à 3.
ZFS : Introduction octobre 2005 (Solaris 10)
Mais bon comme d'hab' l'utilisateur final va d'abord s'en servir sur Mac & Co grâce à une interface graphique adaptée...
[^] # Re: intéressant
Posté par reno . Évalué à 3.
Personnellement, je me souviens d'avoir utilisé un système de versionnement de fichier sur VMS, donc c'est un peu plus vieux que ça.
Mais sinon tu as raison si on prend le nombre d'utilisateurs finaux de VMS + de Solaris 10 + de distrib Linux fournissant Ext3cow, on est probablement loin du compte du nombre d'utilisateurs Mac qui l'utiliseront..
[^] # Re: intéressant
Posté par gpe . Évalué à 6.
Parce que à l'heure des clés USB, des disques durs portables, etc. il est dommage de ne pouvoir utiliser que la FAT32 si on veut être certains de pouvoir partager nos données avec nos amis sous Mac, Windows, Linux, Solaris, etc.
ZFS a une bonne tête, mis à part, son problème de licence. Alors Monsieur Sun un petit effort?
[^] # Re: intéressant
Posté par reno . Évalué à 1.
D'un autre coté, il me semble qu'il est possible de lire des partitions ext2 sous Windows (en ajoutant un soft), c'est toujours mieux que FAT..
[^] # Re: intéressant
Posté par gpe . Évalué à 1.
[^] # Re: intéressant
Posté par Yth (Mastodon) . Évalué à 6.
Le journal n'a pas d'utilité réelle sur une clef USB par exemple.
De plus une partition ext3 peut être lue en tant que partition ext2.
Bon, après il y a sûrement des problèmes, ça ne peut pas être si simple ^^
Yth.
[^] # Re: intéressant
Posté par gpe . Évalué à 2.
[^] # Re: intéressant
Posté par Aldoo . Évalué à 2.
En fait si, il y a un gros problème : EXT? n'est pas installé par défaut sous Windows... Très ballot, si on veut une clé USB universelle ! Ou alors, il faut garder une partition FAT32 pour le pilote EXT2 pour Win.
Sinon, il reste NTFS (ntfs3g sous Linux). Mais ça n'est pas installé sous MacOSX...
[^] # Re: intéressant
Posté par gpe . Évalué à 2.
[^] # Re: intéressant
Posté par B16F4RV4RD1N . Évalué à 3.
Je suis avant tout pour un système communs aux unix, après, pour windows, cela sera à microsoft de s'adapter s'ils veulent l'interoperabilité...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: intéressant
Posté par Psychofox (Mastodon) . Évalué à 3.
Sous windows, j'utilise le driver Ext2fsd :
http://ext2fsd.sourceforge.net/
Cela étant dit, en dehors du filesystem lui-même, il est impossible de partager un FS entre des machines big-endian et little-endian. Je n'ai pas encore trouvé de solution à ce problème (monter sur une machine sparc un disque formaté sur une i386 par exemple).
[^] # Re: intéressant
Posté par B16F4RV4RD1N . Évalué à 2.
J'ai le même répertoire /home pour les différents linux qui sont sur ma machine et cela fonctionne plutôt bien, mais j'aimerais également installer freebsd dessus. C'est plutôt pas mal de se retrouver sur le même bureau avec les même paramètres.
Question subsidiaire : et sous Solaris ?
Par contre il y a un module pour monter du ext3 sous Mac OS X, et il a salement tendance à faire des kernel panic lors de la copie de fichiers...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: intéressant
Posté par Psychofox (Mastodon) . Évalué à 3.
Sous solaris il existe un driver développé par SCO qui est fourni avec lxrun (un emulateur linux) mais il ne monte pas les partitions en écriture :
http://developers.sun.com/solaris/articles/lxrun/
[^] # Re: intéressant
Posté par briaeros007 . Évalué à 6.
problème de licence ?
Zfs est sous licence libre.
Alors que ce soit pas compatible avec la gplv2 mais avec la gplv3 (mais est ce que la gplv3 est compatible gplv2 ? ) c'est vrai, mais c'est pas le probleme de zfs la, c'est plutot le probleme de la licence du noyau linux qui n'accepte pas la licence de zfs.
Et puis on l'a déja sous fuse, et il devrais etre aussous sous freebsd. donc le probleme de licence n'est pas si grand.
Y a meme des entreprises qui font des modules propriétaires , donc c'est tout a fait possible d'avoir un module a part pour mettre zfs.
Alors Monsieur Sun un petit effort?
Celui qui doit faire l'effort c'est pas tant sun que les gens du noyau linux pour passer en gplv3 , si il le veule bien entendu.
On a une entreprise qui fourni un OS complet sous licence libre, et on trouve que c'est nul, qu'il faut que ce soit forcément sous gplv2 ou bsd ?
[^] # Re: intéressant
Posté par reno . Évalué à 3.
Le noyau Linux était sous licence GPLv2 bien avant que ZFS existe, donc dire que c'est un problème du noyau est absurde.
>On a une entreprise qui fourni un OS complet sous licence libre, et on trouve que c'est nul, qu'il faut que ce soit forcément sous gplv2 ou bsd ?
Les incompatibilités entre les licences sont regrettables car cela fragmente la base de code utilisable, certes le probleme existait deja entre la GPLv2 et la BSD mais la c'est une difference de philosophie qui sépare les deux licenses, pas une incompatibilité volontaire entre deux licenses équivalentes..
[^] # Re: intéressant
Posté par briaeros007 . Évalué à 1.
Zfs a pas été concu pour le noyau linux, donc dire que la licence de zfs est nulle parce que pas gplv2 est tout aussi absurde.
Les incompatibilités entre les licences sont regrettables
C'est compatible gplv3 !
(et si on peut passer le noyau en gplv3 par un systeme d'acceptation tacite, comme ce fait les brevets américains: on dis publiquement qu'on souhaite le passer en gplv3. Si au bout de n moi personne ne s'est manifesté (et/ou que les gens qui ce sont manifesté on a réécris leurs code) alors on peut passer en gplv3.
Le probléme est plus politique qu'autre chose.
pas une incompatibilité volontaire entre deux licenses équivalentes.
C'est bien connu, sun a RIEN distribuer de libre et quand ils distribuent ils en veulent particulièrement à la gpl ... mais seulement à la V2, pas à la v3...
Le libre c'est respecter les 4 libertés.
La licence de sun EST libre, n'en déplaise aux aficionados de la gpl.
On rale quand on dis 'ouais si tu veux pas de la gpl ben tu réécris le code !' . Ben eux ils l'ont fait !
Et la on rale en disant 'ah euh oui mais non en fait il faut que vous utilisiez la gplv2'.
Sun a l'interdiction d'utiliser autre chose que la v2 parce que linus l'a décidé ?
Faut arreter la déconnade.
Quand on veut avancer, il faut pas que ce soit toujours la meme partie qui fasse tout le chemin. Les kernels hackers ne veulent pas de zfs ? Soit. Mais qu'on arrete de dire que c'est forcément un probleme de licence et que sun 'ce sont des gros méchants'. C'est un des plus gros contributeurs de code libre, mais ce sont encore de gros méchants ?
[^] # Re: intéressant
Posté par iug . Évalué à 3.
1978:
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1455(...)
1975:
http://portal.acm.org/citation.cfm?id=390016.808467
# IPoT
Posté par Elephant (site web personnel) . Évalué à 10.
ext3cow couplé à IPoT, quelques scripts pour régler à la volée le firewall : je crois qu'on a là une protection ultime :)
[^] # Re: IPoT
Posté par toctoc1 . Évalué à 1.
Suffit de lire cet article :
http://www.lemonde.fr/web/article/0,1-0%402-3244,36-905871%4(...)
pourquoi "prévoir" quand on peut directement lire les pensées des "intruseurz"?
Hein?
[^] # Re: IPoT
Posté par Aldoo . Évalué à 4.
(tiens, j'ai déjà vu ça quelque part... )
# mouai
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Ce ne sont peut etre pas des identifiants de version, mais quand je vois ça
pour moi, ce numéro est tout aussi cryptique qu'un simple numéro de version. Je doute en effet que la majorité des utilisateurs savent faire de tête des conversions de date en nombre de secondes depuis 01/01/70..
Bref, je ne vois pas en quoi c'est un avantage par rapport à un simple numéro de serie (pour l'utilisateur j'entend).
À moins qu'on puisse indiquer une vraie date genre foo.txt@2006-04-21_12h35
(oui, j'ai pas lu la doc, la flemme d'ouvrir tout ces pdf)
[^] # Re: mouai
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
Par ailleurs, ce numéro est le nombre de secondes écoulées depuis le 1er Janvier 1970, soit un nombre « epoch » ou temps Unix.
En outre, d'après la FAQ, les développeurs envisagent de créer des « macro » comme @yesterdayday ou @lastweek.
[^] # Re: mouai
Posté par Antoine . Évalué à 0.
C'est totalement bidon comme argument.
Le même genre de "macros" serait tout aussi possible avec des numéros de révisions, puisqu'en général on stocke tout de même la date correspondant au numéro de révision, n'est-ce pas :)
(par exemple Subversion, Mercurial & co permettent de récupérer une révision par date)
[^] # Re: mouai
Posté par Gniarf . Évalué à 1.
parce qu'une date ca veut dire quelque chose mais un numero de version, rien. ils ont un ordre ? les dates aussi. c'est plus lisible ? seulement quand tu auras 3-4 versions, pas plus.
en particulier avoir 37 numéros de versions de ton CV, une créée à chaque correction, ne veut rien dire. par contre une date derriere, oui.
quand tu auras plusieurs dizaines de fichiers différents, chacun avec sa rimbambelle de versions, ca sera plus facile de reperer les fichiers remontant à une date précise d plutot que d'interroger chaque version cv.txt,1 cv.txt,2 cv.txt,3 ... cv.txt,42 pour retrouver la bonne. par exemple le 9 mai 2006 ta bio.txt en sera à la version 4 et ton experience.txt en sera à la version 12 : pas très parlant si tu veux raisonner par date.
(quelque part je rappelle que c'est juste une question de présentation)
maintenant, si tu cherchais un système de fichiers qui te garde automatiquement l'ancienne version des fichiers que tu modifies au fur et à mesure, ben ext3cow n'est pas fait pour ça.
[^] # Re: mouai
Posté par Antoine . Évalué à 2.
Je répète puisque tu as l'air un peu malcomprenant : l'identifiant de révision interne n'est pas obligé de refléter la donnée affichée à l'utilisateur, ni celle que l'utilisateur doit entrer.
Maintenant d'un point de vue informatique il est évident qu'utiliser des identifiants séquentiels comme identifiants internes a beaucoup plus de sens. Ne serait-ce que parce que si l'utilisateur change l'heure de son système, le versionnage part en couille.
en particulier avoir 37 numéros de versions de ton CV, une créée à chaque correction, ne veut rien dire.
Bien sûr que si. Non seulement je sais immédiatement qu'il y a 37 versions (numérotées de 1 à 37), mais je sais aussi que la révision précédant immédiatement la numéro 37 est la numéro 36 (ce qui me permet par exemple, si je me rends compte que j'ai fait une erreur, de retrouver la version juste avant), et ainsi de suite.
Ce sont des informations tout à fait utiles.
(évidemment au bout de 8317 révisions sur un dépôt SVN ça commence à être un peu futile, mais la plupart des gens n'accumulent pas 8317 révisions de leurs petits documents à eux)
(quelque part je rappelle que c'est juste une question de présentation)
Ha, l'argument initial c'est bien que la date est utilisée comme identifiant interne à la place d'un numéro de révision (ce qui serait, aux dires de l'auteur de la dépêche, un véritable avantage).
Je suis d'accord que c'est juste une question de présentation, et c'est pour ça que l'argument initial est foireux (la couche présentation n'est pas dans le noyau et encore moins dans le filesystem, enfin j'espère).
pas très parlant si tu veux raisonner par date
Oui, si on veut raisonner par date, il est préférable d'utiliser des dates : merci de la tautologie.
[^] # Re: mouai
Posté par Gniarf . Évalué à 3.
chic. dans 5 minutes tu vas m'expliquer qu'on utilise les noms de fichiers et non pas les inodes pour travailler tous les jours ? j'espère que tu ne me traiteras pas de nazi mangeur de caca au passage, j'aurais trop trop honte :(
> Maintenant d'un point de vue informatique il est évident qu'utiliser des identifiants séquentiels comme identifiants internes a beaucoup plus de sens. Ne serait-ce que parce que si l'utilisateur change l'heure de son système, le versionnage part en couille.
euh... non. déjà, seul root peut changer l'heure du système sur un système décement configuré, ça va peut-être te donner un indice sur le fait qu'on ne la change pas comme ça juste pour s'amuser. et les systèmes distribués de gestion de versions te demandent d'être à l'heure, merci.
et que tu ressortes tes identifiants séquentiels montre bien que tu confonds avec d'autres systèmes : là c'est le système de fichiers qui est versionné, pas chaque fichier un par un. la date de snapshot d'un fichier a sûrement cent fois plus de sens qu'un "identifiant interne" qui ne veut rien dire pour le système ni pour toi et surtout qui ne voudra rien dire par rapport à un autre fichier avec un historique différent. et en terme de stockage, 64 bits ca tiendra encore longtemps.
tu peux t'accrocher à une vision de numéros de version qui veulent dire quelque chose comme pour mon exemple de cv.txt,1 cv.txt,2 cv.txt,3 mais comme tu ne feras pas toi-même à la main de snapshot à chaque fois que tu auras modifié un fichier (parce que c'est vite bien relou) tu risques d'utiliser ça comme un undelete du pauvre, comme une sauvegarde imparfaite de tes fichiers si tu lances une tache cron genre toutes les heures pour faire ces snapshots. tu n'auras pas tout perdu, mais il risque de te manquer des modifs. je pense que ca peut etre utile mais ce n'est pas le meilleur usage possible de ext3cow.
le fonctionnement (et le but) de ext3cow ne te convient peut-être pas parce qu'il ne remplit pas TON besoin ou ce que tu espérais trouver. je te rassure, j'ai été déçu les 2-3 fois où je retombais dessus en cherchant sûrement la même chose que toi, de quoi garder automatiquement des cv.txt,1 cv.txt,2 cv.txt,3 (...) chaque fois que j'éditais mon cv.txt
(il y a d'autres systèmes qui font ça très bien depuis 20 ans, hein, par exemple VMS : http://en.wikipedia.org/wiki/OpenVMS_filesystem#Disk_organiz(...) : il va gérer les ,1 ,2 ,3 tout seul parce que lui n'a pas besoin d'un système de snapshot)
> > en particulier avoir 37 numéros de versions de ton CV, une créée à chaque correction, ne veut rien dire.
> Bien sûr que si. Non seulement je sais immédiatement qu'il y a 37 versions (numérotées de 1 à 37)
quel génie. malheureusement tu vas vite supprimer, archiver des versions intermédiaires pour des raisons X ou Y comme garder des bonnes versions et faire de la place. donc ton max_version = nombre_de_versions il va en prendre un coup.
et c'est toi qui parle de tautologie quand tu m'apprends que la révision précédant immédiatement la numéro 37 est la numéro 36 ?
si tu as des difficultés pour classer 1178850314 11788683145 1181850222, je te rassure, ton ordinateur est là pour t'aider comme iil t'aidera déjà pour classer 35 36 37 sans que tu t'en rendes compte.
> évidemment au bout de 8317 révisions sur un dépôt SVN
ding-dong : on ne parle définitivement pas d'un dépot SVN ou équivalent.
[^] # Re: mouai
Posté par Antoine . Évalué à 1.
Et ? La plupart des utilisateurs ont l'accès root sur leur ordinateur perso.
Qu'il faille un mot de passe pour changer l'heure ne change rien au fait qu'on peut la changer, et donc que baser un versionnage sur les timestamps est une connerie.
D'ailleurs il n'y a même pas besoin d'une bourde de l'utilisateur : il suffit d'une couille quelconque de NTP ou toute autre affre liée à la complexité des systèmes Linux contemporains.
je pense que ca peut etre utile mais ce n'est pas le meilleur usage possible de ext3cow.
Je suis bien d'accord, à mon avis ça ne remplace pas un système étudié pour comme Mercurial ou SVN. Maintenant c'est bien sous cet angle-là que c'est présenté ici, donc...
malheureusement tu vas vite supprimer, archiver des versions intermédiaires pour des raisons X ou Y comme garder des bonnes versions et faire de la place
Je ne me suis jamais amusé à supprimer des versions intermédiaires dans un système de gestion de versions...
Quant au fait d'archiver, c'est par construction indépendant des usages évoqués ici.
et c'est toi qui parle de tautologie quand tu m'apprends que la révision précédant immédiatement la numéro 37 est la numéro 36 ?
C'est précisément parce que c'est une tautologie que c'est un point fort de la numérotation séquentielle.
(d'ailleurs, ce n'est pas une tautologie au sens d'une proposition logique vraie par construction, mais une vérité mathématique triviale)
# A quand la versionnalisation du future?
Posté par dmg . Évalué à 6.
Ca serait bien j'aurais plus qu'a faire un "cat these.tex.01012009" pour avoir ma these :p
[^] # Re: A quand la versionnalisation du future?
Posté par Raphaël G. (site web personnel) . Évalué à 9.
Ensuite même si tu pouvais récupérer dès aujourd'hui cette these en faisant un saut dans le futur tu aurais des problèmes divers...
1 - tu devras écrire cette thèse de toute manière et acquérir les connaissances (parce que dans une boucle il faut apporter le résultat a un moment)
2 - certaines idées et concepts te paraîtrons incompréhensible ou absurde (car tu n'auras pas encore fait les expériences)
Bref, le saut dans le futur et dans le passé ça implique pas mal de conséquences...
Un autre problème est que tu devras choisir de quelle réalité tu prends la thèse, car j'imagine que l'univers a une certaine logique :
Action => Conséquence
Et que pour que on ai :
Conséquence => Action
Il faut que la conséquence appartienne a un univers 1 et l'action a un univers 2 parallèle et clone du premier...
Comme quoi même si on arrive a inventer le saut dans le temps on va avoir des soucis de cohérence a se taper si l'univers ne s'en charge pas pour nous.
# en mieux
Posté par z a . Évalué à 5.
http://wayback.sourceforge.net/
http://n0x.org/copyfs/
(entre autres)
# snapshot
Posté par M . Évalué à 7.
[user@machine] snapshot
Snapshot on . 1057845484
Arf, c'est qu'un système de snapshot, moi qui croyait qu'a chaque modif du fichier (open/close ?) une version était crée...
[^] # Re: snapshot
Posté par Mildred (site web personnel) . Évalué à 4.
# Intérêt ?
Posté par Xavier Maillard . Évalué à 3.
Suis-je le seul à penser que les bons vieux backup de dino sont les seules solutions *fiables* pour garder une trace/l'historique des modifications faites sur un système de fichiers ?
Et puis quand je lis que le système consomme peu de ressources de stockages (entre 5 et 15%), je me gausse. 15%, ça commence à se chiffrer pour un truc qui in fine, ne servira que rarement. Où alors je n'ai pas bien saisi l'utilité de la chose.
P.S: au fait, Emacs fait ça depuis des années, c'est simple, il laisse trainer des fichiers partout, du coup je retrouve facilement les X dernières versions de chaque fichier modifié sans me gratter la tête
[^] # Re: Intérêt ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: Intérêt ?
Posté par Gniarf . Évalué à 5.
[^] # Re: Intérêt ?
Posté par fabien . Évalué à 2.
et d'une partition a une autre (clef usb formaté en ext3cow) ?
et quand on supprime le fichier ?
et je pense que si on fais un tar et que l'on détar dans un autre repertoire on dois perdre l'histo aussi...
[^] # Re: Intérêt ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Je ne pense pas que l'historique puisse suivre à moins de ne faire un dump d'ext3 (et encore). De même pour tar/détar et je pense qu'il vaut mieux faire soi-même des tests. Quand on supprime un fichier, son historique est conservé.
Je précise que je ne suis pas du tout spécialiste des systèmes de fichiers.
[^] # Re: Intérêt ?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
$ cd .snapshot/hourly/12
$ cp machin-truc ~/la/ou/ca/devait/etre/avant
C'est très pratique pour réparer des erreurs. Par exemple, essayes « rm -fr .git/ », ou d'autres trucs plus vicieux genre « find . -quelquechose -exec perl -pi -e 's/mahin/truc/' » qui te corromp les fichiers de ton gestionnaire de versions, ou une connerie sur du code pas (encore) commité, ...
Par exemple, j'ai déjà eu à utiliser le système ci-dessus en arrivant en temps que formateur sur un site. Bon, tout est installé comme convenu dans le répertoire machin/bidule. Sauf qu'il y avait un cron job qui faisait rm -fr machin/bidule/ toutes les nuits :-(.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.