Bonjour,

J'ai un problème avec la copie de fichiers et dossiers depuis un ordinateur sous Ubuntu 18.04, vers un nouvel ordinateur sous Windows 10.
Tous mes dossiers et fichiers (très importants pour le travail) sont sur deux disques durs externes, chiffrés avec Veracrypt sous Ubuntu, et avec une partition NTFS/exFAT/HPFS.
Tout fonctionnait bien avec ces disques sous Ubuntu. Mais le problème arrive quand je veux lire ces fichiers ou les copier sous Windows 10. J'ai plusieurs problèmes simultanés (sous Windows 10) :

1/ de nombreux fichiers apparaissent en doublons avec un point devant. Il est impossible de lire ou de supprimer ces fichiers/dossiers avec un point devant. Alors que j'ai coché sous Windows l'option pour ne plus afficher les fichiers cachés, ils sont toujours visibles.

2/ plusieurs fichiers et dossiers sont visuellement présents (sur le disque dur externe et quand je les copie-colle sur le disque de l'ordi windows), mais sous Windows il est impossible de les ouvrir. J'ai différents messages d'erreur qui indiquent que le fichier ou le dossier est "introuvable" ou "n'existe pas", etc.

3/ Lors du copier-coller de dossiers du disque dur externe vers le disque sous Windows, certains fichiers et dossiers n'ont pas pu être copié, m'indiquant un message d'erreur "introuvable" ou "n'existe pas". Alors que ces mêmes fichiers ou dossiers sont lisibles avec ce même disque dur externe sous Ubuntu (j'ai fais plusieurs essais dans les deux sens).

Pour faire le test, j'ai copier-coller ces mêmes fichiers/dossiers depuis Ubuntu sur une clé USB partitionné en FAT32, puis à partir de cette clé je les ai copié sur le disque de l'ordi windows. Et cette fois ça fonctionne, les fichiers/dossiers sont reconnus et lus correctement.
J'en ai déduis que le problème vient probablement de mes disques durs externe. D'ailleurs comme je les ouvre avec Veracrypt sous Windows, ça m'affiche une erreur de disque. Windows propose de réparer. ce que j'ai fais sur l'un des disques, et ça m'a juste supprimé les fichiers corrompus en question sur le disque dur externe.

J'ai alors reformaté l'un des disques durs externes à partir d'Ubuntu en format NTFS. J'ai remis dessus, toujours via Ubuntu, le fichiers/dossiers qui posaient problème. En remettant ce disque dur externe sous windows, la même chose se reproduit. les mêmes fichiers/dossiers d'avant sont lisibles sous Ubuntu mais ne le sont pas sous Windows 10, et les mêmes autres sont doublés avec des points devant.

J'aimerais pouvoir faire une bonne copie clean de l'ensemble de mes fichiers/dossiers depuis Ubuntu vers Windows.
Avez vous une solution svp ?
Et savez-vous pourquoi ces dossiers/fichiers se lisent correctement sur ces disques durs externe sous Ubuntu et pourquoi ça plante sous Windows ?
Car j'ai besoin que l'ensemble de ces fichiers/dossiers soient bien lisibles sous Ubuntu et sous Windows sur ces deux ordis.

Je fouille depuis hier sur internet pour trouver des réponses, et ne trouve que des bribes sans vraiment de solutions à ces problèmes spécifiques.

merci d'avance !
PIco
Bonsoir.
Dans l'ensemble windows considère que le nom d'un fichier ne doit pas commencer par un POINT. A toi de d'adapter.

Pour le second problème, les noms de fichiers ont certainement des caractéres spécaux interdits par windows. Cependant , on oublie souvent qu'un nom de fichier ne doit pas commencer ou finir par espace. Peux-tu indiquer quelques noms de fichiers à problème.
Bonjour,

Ce n'est pas moi qui ait nommé les noms de fichiers commençant par un point, c'est Windows. Au moment de la copie de mes fichiers nommés normalement, windows a rajouté une copie de fichiers avec un point devant. Ils sont en fait supprimables, donc ce problème est réglé.

Pour les autres noms de fichiers, (Ce sont des fichiers PDF. ou DOC., ODT ou ODF. ) je ne pense pas que ce soit le problème. Car ils sont juste nommés avec des lettres, des chiffres, des "points" et parfois des "_" ou des " : ". Et je fais bien attention avec les espaces pour le tri de mes fichiers. Des fichiers avec ces caractères s'ouvrent généralement, d'autres non. J'ai essayé de modifier les noms des fichiers qui ne s'ouvrent pas sous windows, et la modification ne fonctionne pas et sur certains fichiers une alerte s'ajoute disant que le fichier est introuvable.
à partir de mon disque dur externe ou depuis le disque de l'ordi sous windows, quand je double-clic sur certains de ces fichiers, ça ne s'ouvre pas et ça m'indique un message d'erreur "nom du répertoire non valide". Mais quand je fais "ouvrir avec" et que je sélectionne LIbreOffice, ça s'ouvre. j'ai "enregistré sous" le fichiers ailleurs. et ce second fichier, le double-clic fonctionne, mais toujours pas sur le premier.
Pour d'autres fichiers, même avec le "ouvrir sous" ça ne s'ouvre pas.

J'ai essayé de reformater l'un des disques dur externe en FAT32. Et j'ai mis ces fichiers qui posent problème dessus depuis Ubuntu. Et cette fois, Windows les ouvre et les lit sans problème. (même s'il rajoute encore ces mêmes fichiers avec des points devant).

Du coup je me demande si le problème ne vient pas d'un transfert de fichiers qui passait par du NTFS ? Et qu'il ne faudrait pas que je tout le transfert de ces fichiers/dossiers via le disque en FAT32 ?
ou alors je pensais résoudre ce problème de transfert de fichiers en passant pas Spideroak d'un ordi à l'autre ?
Autre problème que je viens de constater...
J'ai pour habitude de m'envoyer par mail le fichier d'écriture en cours comme sauvegarde temporaire supplémentaire. Et là, au téléchargement du fichier ODT que je me suis envoyé hier depuis windows, avec juste l'option "ouvrir le fichier", il ne s'ouvre pas et m'affiche ce message d'erreur : Accès à C:\Users\apreg\AppData\Local\Temp\Chapitre 5. Généralisation de la cause. V2.odt refusé.
ça ne me l'avait jamais fait sous Ubuntu...
Quand je fais directement "enregistrer sous" par contre je peux ensuite l'ouvrir.

Mais tout ça m'inquiète, car je crains pour la sauvegarde de mes fichiers...
Bonjour
Le caractère : (deux points) fait partie de la liste des caractères interdits dans les noms de fichiers stockés dans les partitions ntfs
Je ne pense pas que la solution soit de stocker dans des partitions au format FAT mais de renommer les fichiers ou les répertoires les accueillant

Nota, il existe une option "windows_names" empêchant de créer de tels fichiers ou répertoires. Mais si tu la mets alors qu'il en existe, ils deviendront inaccessibles.
Ok je comprends pour les deux points. Mais je n'ai que deux fichiers qui ne s'ouvrent pas qui ont les "deux points". Tous les autres ont des caractères autorisés.
Et ce même fichier avec " deux points", quand je l'ai transférer avec ma clé ubs en FAT32, windows l'a ouvert, et a juste supprimer de lui même les "deux points" dans le nom du fichier. Mais quand ça passe par le disque dur en NTFS, ça bloque.
C'est pour ça que je me demande si ce n'est pas le format de la partition qui coince. Vu que ces mêmes fichiers qui bloquent en passant par le NTFS (que le nom de fichier soit correct ou non pour windows) ne bloquent pas en passant par du FAT32
Pour l'un de ceux que tu crois correct peux-tu poster le retour complet du nom d'acces par exemple
"cp /le nom complet /dev/null"
Donne aussi ce retour 
cat /etc/fstab   | grep -v "#"
Je ne suis pas sur de la première commande rentré...
pico@pico-Latitude-3480:~$ cp /archives anderlecht traduction.odt /dev/null
cp: la cible '/dev/null' n'est pas un répertoire
pico@pico-Latitude-3480:~$ cat /etc/fstab   | grep -v "#"
UUID=f72b268b-7bee-4469-9d94-876f39fcfa7f /               ext4    errors=remount-ro 0       1
UUID=767E-FB7D  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
pico@pico-Latitude-3480:~$
et un autre point, c'est que sous Ubuntu, SpiderOak ne détecte pas mes disques durs externes, alors qu'ils sont détecté par SpiderOak sous Windows. Je ne sais pas si le problème est lié, mais je donne l'info au cas où
Ta codification d'entrée est mauvaise
C'est probablement cela... J'ai mis entre quote car il y a des espaces 
cp "/home/pico/archives anderlecht traduction.odt" /dev/null
Tu vas aussi préciser quelle est la partition de sortie dans ces listes 
sudo blkid | grep ntfs
ls -ls /media/pico
ok merci.
voici : 
pico@pico-Latitude-3480:~$ cp "/home/pico/archives anderlecht traduction.odt" /dev/null
cp: impossible d'évaluer '/home/pico/archives anderlecht traduction.odt': Aucun fichier ou dossier de ce type
et ensuite : 
pico@pico-Latitude-3480:~$ sudo blkid | grep ntfs
pico@pico-Latitude-3480:~$ ls -ls /media/pico
total 4
4 drwxr-xr-x 2 root root 4096 févr. 28  2020 SHEHERAZADE
pico@pico-Latitude-3480:~$
En fait, mes disques se montent automatiquement sur le bureau, et celui crypté je peux le monter avec veracrypt. je peux lire les deux disques normalement. C'est SpiderOak qui ne les détecte pas. et comme les données sont sur ces disques, j'aurais voulu les envoyer sur mon compte SpiderOak. Mais il les détecte par contre sous Windows.
Manifestement, tu ne sais pas où est stocké ton fichier...
Je te propose cette commande pour essayer de le trouver 
sudo find / -name "archives anderlecht traduction.odt"


Pour ton application, je ne la connais pas, le mieux serait d'ouvrir une autre discussion lorsque ce problème sera réglé.
Le fichier est stocké dans un dossier sur le bureau...
Voici la réponse de la commande : 
pico@pico-Latitude-3480:~$ sudo find / -name "archives anderlecht traduction.odt"
find: ‘/run/user/1000/gvfs’: Permission non accordée
/home/pico/Bureau/Archives /archives anderlecht traduction.odt
Est-ce bon ? je ne comprends pas trop en fait la...
Oui c'est bon
Mais on voit bien que le niveau supérieur n'est pas correct....
donc on renomme en supprimant l'espace de droite dans le nom du sous-répertoire 
mv "Bureau/Archives "  Bureau/Archives
Puis tu pourras regarder si ce problème est résolu.
Je ne comprends pas. les fichiers et dossiers sont mal enregistrés ? ils ne sont pas enregistrés avec les bons chemins ?

Je ne vois pas comment renommer et utiliser la ligne de commande que tu viens de m'indiquer...
Tu fais un copier/coller de la commande
La conséquence sera que le répertoire "Archives " qui se termine par un espace deviendra "Archives"
OK c'est ce que j'avais fait. Merci!
Mais du coup, le problème provient d'une mauvaise nomination des dossiers ?
La c'était pour un fichier qui fonctionnait bien. Est-ce que je dois refaire les mêmes manip et commandes avec un fichier qui fonctionne mal pour vérifier ?