[gull] samba client

[Marc SCHAEFER]

On Fri, Oct 18, 2019 at 06:47:26PM +0200, Cédric BRINER wrote:
> >D'un autre côté, cela ne permettrait que de faire des choses en ligne
> >de commande, donc, pour le cas présent, scp semble plus simple, non?
> Ah... je n'avais pas vu ça comme ça. C'est vrai que tout d'un coup ça
> devient moins sexy.

Par contre, il reste plusieurs approches:

   1) tenter d'intégrer les outils libres Samba dans le navigateur
     de fichier de chaque plateforme

        limité au GUI, pas trop gênant pour les Microsoft ou Mac OS
        users classiques, très gênant pour moi qui n'aime pas les
        GUIs

   2) tenter d'intégrer les outils libres Samba dans un truc genre
     fuse (user-space filesystem)

        comme un vrai fs

Mais en fait, pourquoi réinventer la roue?

- sous MacOS X, on a 2 sous forme de NFS client et
sshfs https://github.com/osxfuse/osxfuse/wiki/SSHFS

- sous Microsoft, ben on a le client SMB de base de l'OS,
capable d'interagir un minimum avec Samba, ainsi que ...
sshfs: https://github.com/billziss-gh/sshfs-win

Et, pour les fs locaux, ben Linux monte à peu près tout
aujourd'hui, même du BitLocker, à voir:

   https://www.linuxuprising.com/2019/04/how-to-mount-bitlocker-encrypted.html

   Ne pas oublier de faire un reboot de Microsoft ou un
   shift-halt pour éviter de la corruption (un simple halt
   sous Microsoft fait en fait un suspend-to-disk, sans garantie sur
   l'état du fs -- à faire aussi avant tout ntfsclone genre via
   clonezilla).

Donc, si le centre de compatibilité est Linux, il n'y a absolument
aucun problème à se passer de exfat ou autres solutions brevetées
ou propriétaires.

Le problème de compatibilité, en fait, n'existe que directement
entre Mac OS X et Microsoft.