Excellent !

Quelques nouvelles depuis tout ce temps.. Je suis passé en beta ainsi ça marche bien mieux qu'avant. Un disque dur devraient pouvoir être lu sans problème. L'extension FUSE (fosmount) a été améliorée néanmoins lorsqu'un dossier est relativement gros, le listage des fichiers peut sembler un peu lent (extrêmement visible avec le dossier SYSTEME :-s).
Par contre l'outils non dépendant de FUSE (et ne permettant donc pas de monter le système dans l'arborescence) est plus rapide (fosread).

J'ai fais deux packages Ubuntu Feisty. un i386 et un amd64
http://download.gna.org/fosfat/fosfat_0 … 0_i386.deb
http://download.gna.org/fosfat/fosfat_0 … _amd64.deb

Bien sûr les sources sont disponibles sous forme d'archive : http://download.gna.org/fosfat/fosfat_0.2.0.orig.tar.gz

Mais il est plus judicieux d'utiliser le dernier trunk.
voir directement le site : http://home.gna.org/fosfat/

Pour monter un disque, j'ai également changé les commandes, ainsi (par exemple):
pour un disque dur

mkdir ~/fos
fosmount -a /dev/sda ~/fos

une disquette

fosmount /dev/fd0 ~/fos

pour plus d'info, fosmount --help

Et comme toujours,

fusermount -u ~/fos

pour le démontage..

En ce qui concerne les autres outils, pour fosread (par exemple):

fosread -a /dev/sda list systeme

liste le contenu du dossier SYSTEME
pour plus d'info: fosread --help


Et j'ai également rajouté un petit outil de conversion des fichiers textes Smaky en ISO-8859-1

smascii smaky_file converted_file --unix

permet donc de convertir le fichier smaky_file (préalablement récupéré à l'aide de fosmount ou fosread)
--unix sert à convertir les retours à la ligne en Line Feed. Dans le cas contraire ils resteront inchangés et donc en Carriage Return.

Je prévois également de faire un logiciel pour convertir dans un premier temps les fichiers .IMAGE en un format standard comme PNG.

Tout ceci n'est donc pas stable.. ainsi il ne faut pas s'étonner s'il y arrive qu'un segfault se pointe. Je n'ai pas pu tester tous les cas à fond. Et sûrement que certains fichiers hautement fragmentés posent un problème, mais j'espère pas trop. Certaines erreurs me sont déjà connues mais pour les régler, il me manque encore quelques données sur cette FAT.
Bref, vu que le nombre de potentiels utilisateurs de Smaky est extrêmement faible, je n'attend pas de rapport d'erreur :-). Mais peu importe.. qui sait..

Et plop, une nouvelle version beta estampillée 0.2.2 avec principalement une meilleur stabilité. Et à part des corrections de bugs divers et variés il y a qu'en même deux nouveautés.

* Tout d'abord un logger est désormais intégré à la librairie et peut être activé et désactivé au besoin.. Celui-ci se traduit donc par l'option --fos-logger depuis les applications fosread et fosmount. S'il est utilisé avec fosmount, alors le processus ne se détachera pas de la console, comme c'est déjà le cas avec le debugger de FUSE (--fuse-debugger).

* La deuxième nouveauté concerne le choix entre un disque dur et une disquette.. le FOS ne débutant pas au même block avec les deux types de média, dans les versions précédentes (<=0.2.1) il était nécessaire d'utiliser l'option -a (ou --harddisk) afin qu'un disque dur soit monté correctement. Sinon par défaut, c'était le choix de la disquette. Désormais la librairie va automatiquement détecter le bon type et faire le choix pour vous. Néanmoins des options ont été conservées pour forcer le type (-a, --harddisk) et (-f, --floppydisk) dans le cas où la détection échouerait (ce qui est très peu probable , à moins d'essayer de monter autre chose qu'un système FOS).

Et pour finir, je me suis amusé à faire un logo au projet.. question de ne plus utiliser une image de Blupi qui n'était pas de moi (j'avais qu'en même demandé l'autorisation à un dév. d'Epsitec). Alors voici Fosblup qui s'est mit en CC-by-sa.

Sa forme correspond (plus ou moins) à une des molécules de phosphate (Fosfat).


Les paquets pour Ubuntu Feisty Fawn:
amd64 : http://download.gna.org/fosfat/fosfat_0 … _amd64.deb
i386 : http://download.gna.org/fosfat/fosfat_0 … 0_i386.deb

Et le reste comme d'hab.:
sources : http://download.gna.org/fosfat/fosfat_0.2.2.orig.tar.gz
site : http://home.gna.org/fosfat/
svn :

svn co http://svn.gna.org/svn/fosfat/trunk fosfat

Et non, la réincarnation de Blupi en Fosblup n'était pas du vent mais bien du phosphate. Il ne pouvait donc pas s'envoler et était alors obligé de continuer son travail pour offrir une nouvelle version estampillée 0.3.0.

Quoi de neuf?

* Les liens symboliques
L'outil indépendant de FUSE (fosread) gère désormais correctement les liens symboliques du Smaky FOS. C.-à-d. qu'ils ne sont plus visibles en tant que fichier, mais bien en tant que lien et donc navigables comme des dossiers.

* Multiple disques
La libfosfat peut maintenant gérer plusieurs disques dans un même programme.

* Le mode undelete
La librairie peut désormais travailler avec les fichiers effacés.. Ce qui implique qu'il est possible de restaurer des fichiers qu'on aurait détruit par mégarde. Néanmoins j'ai activé cette option uniquement sur l'outil fosread. Je dois vous avouer que mes premiers tests avec mon disque dur Smaky étaient très amusants.. j'ai retrouvés des choses vraiment vieilles.. en gros.. ça marche impec

Alors c'est simple..  voyez ci-dessous:

En exécutant simplement fosread comme avec les version 0.2.x, le contenu est bien listé avec les fichiers réellement existants.

$ fosread /dev/sda list /progr
Smaky disk #545_MB:
path: progr

        size creation         last change      last view        filename
        ---- --------         -----------      ---------        --------
d--        0 2000-00-00 00:00 2000-00-00 00:00 2000-00-00 00:00 .
d--    12800 1997-04-12 11:30 2005-05-14 18:21 2005-05-14 18:21 pascal
d--    12800 1997-04-12 11:32 2000-01-23 13:04 2000-05-04 20:28 rs
d--    12800 1997-04-12 11:30 2000-01-23 13:04 2000-05-04 20:27 chargeur
-h-      128 1993-03-12 17:45 1997-04-12 11:32 1999-12-27 11:40 start_dir.info
d--    12800 1997-04-12 11:28 2001-02-21 14:43 2001-02-21 14:43 basic

d:directory  l:link  h:hidden  e:encoded    (X):undelete

En ajoutant l'option `-u` ou `--undelete`, on découvre un nouveau fichier signalé par un (X), celui-ci étant effacé.

$ fosread /dev/sda list progr -u
Smaky disk #545_MB:
path: progr

        size creation         last change      last view        filename
        ---- --------         -----------      ---------        --------
d--        0 2000-00-00 00:00 2000-00-00 00:00 2000-00-00 00:00 .
---     1735 1999-12-08 13:03 1999-12-08 13:03 1999-12-08 13:03 couleur.bas (X)
d--    12800 1997-04-12 11:30 2005-05-14 18:21 2005-05-14 18:21 pascal
d--    12800 1997-04-12 11:32 2000-01-23 13:04 2000-05-04 20:28 rs
d--    12800 1997-04-12 11:30 2000-01-23 13:04 2000-05-04 20:27 chargeur
-h-      128 1993-03-12 17:45 1997-04-12 11:32 1999-12-27 11:40 start_dir.info
d--    12800 1997-04-12 11:28 2001-02-21 14:43 2001-02-21 14:43 basic

d:directory  l:link  h:hidden  e:encoded    (X):undelete

On peut alors tenter une récupération.. pour cela il suffit de faire exactement comme avec un fichier "normal".

$ fosread /dev/sda get progr/couleur.bas -u
Smaky disk #545_MB:
File "progr/couleur.bas" is copying ...
 1792 bytes
 1844 bytes
Okay..

Et dans cette exemple il a pu être lu sans aucun problème! Bien sûr, il se peut que des blocs de DATA soit détruits à cause d'autres fichiers.. Mais dans ce cas, soit le fichier est corrompu, soit fosread n'arrive tout simplement pas à le lire.
En cas d'échec il est judicieux d'activer le logger de la libfosfat avec l'option `-l`ou `--fos-logger`. En mode "undelete" il est normal que le logger retourne beaucoup d'erreurs. Simplement car il tente de suivre des dossiers effacés sans succès. Néanmoins, si l'undelete n'est pas activé et que des erreurs sont visibles il peut y avoir deux raisons. Tout d'abord j'ai peut être laissé un bug et dans ce cas faut me tenir au courant, ou alors votre disque à une corruption quelque part. Mais dans tous les cas il ne devrait pas y avoir de plantage, mais juste des messages d'erreur en retour. Un plantage serait alors aussi une faute de ma part.

* Le support de Window$ 9x/NT
N'étant pas un fan de ce cher Window$, mais étant conscient que ça puisse qu'en même rendre service à d'autres utilisateurs malheureusement encore prisonniés par Microsoft.. J'ai fais un petit effort en portant une partie des outils sous ce système (bien sûr, ce qui concerne FUSE n'est pas dispo avec Window$).
Alors tout d'abord c'est complètement expérimental, c'est tout juste si j'ai testé.. mais au premier abord ça semble marcher (en tout cas avec WinXP). Le plus gros souci c'était d'avoir un accès bas niveau au disque dur avec ce foutu OS. J'ai donc trouvé un morceau de code C++ qui permet de le faire pour Win9x et NT en théorie. Il m'a juste fallu écrire un petit wrapper C par-dessus afin que je puisse l'utiliser avec la libfosfat.

La ligne de commande de fosread est semblable à la version Linux.. la seul différence c'est le paramètre du périphérique..
Avec Linux: fosread /dev/sda list (ou /dev/fd0 voir même une image disque)
Avec Window$: fosread.exe d list (pour le disque d, mettre a pour la disquette, etc,..)
La version Window$ ne peut pas non plus travailler avec des images disques.. je pourrais le faire, donc peut être dans une futur version.


Ainsi il y a donc trois versions binaires disponibles:
i386: http://download.gna.org/fosfat/fosfat_0 … 0_i386.deb (Gutsy Gibbon)
amd64: http://download.gna.org/fosfat/fosfat_0 … _amd64.deb (Gutsy Gibbon)
Win9x/NT: http://download.gna.org/fosfat/fosfat_0.3.0.win32.zip

et les sources: http://download.gna.org/fosfat/fosfat_0.3.0.orig.tar.gz


Et le site comme d'hab: http://home.gna.org/fosfat/

Je me suis enfin intéressé aux fichiers .COLOR.. qui ne sont guère plus compliqués que les .IMAGE (monochrome). La différence intervient uniquement à la façon d'interpréter les données décodées. L'algorithme de décodage est exactement le même que pour le monochrome.
Au lieu d'avoir 1 bit par pixel, il y a 4 bits par pixel. A noter également l'existence d'une colormap en en-tête. Celle-ci contient les correspondances RGB des couleurs de 0 à 15.

Je n'ai pas encore fais de nouvelle release de la lib, mais toutes les modifications sont dans le trunk.

La conversion des .COLOR en .XPM se fait à la volée. De la même manière que pour les .IMAGE en .PBM. L'arborescence visible dans le screenshot est le disque de modèle (disponible avec l'installateur du Smaky Infini http://www.smaky.ch/~infini/ ) monté dans un répertoire de mon home (~/documents/developement/dev.linux/linux.c/c.smaky/dev/) à l'aide de l'extension fuse, fosmount (options -i et -j pour activer les conversions à la volée).


http://gamesover.ch/prov/smaky/smaky.disk.COLOR.1.png


Les fichiers PBM sont utilisés pour le monochrome, et XPM2 pour la couleur. C'est pour cela que les miniatures ne sont pas visibles dans Nautilus. XPM2 n'est pas lisible par la majorité des applications. Je n'ai trouvé que Gimp et l'outil SXPM pour les lire. Je n'utilise pas le format XPM le plus répandu (XPM1|3) par commodité. Les petites fenêtres des images .COLOR sont donc créées par http://www.xfree86.org/current/sxpm.1.html .


http://gamesover.ch/prov/smaky/smaky.disk.COLOR.2.png