Reprise du message précédent :
bon ben alors je reste sur gnome 3 lol

Sinon, il y a XFCE, aussi, dans le léger et très personnalisable…

Ou i3, ou awesome, ou ratpoison, ou…

E24.

Je rencontre un souci exotique avec mon Arch, quand je veux copier certains dossiers de mon répertoire de musique :
 

 
A priori, je ne trouve aucune raison logique au niveau du nom du dossier, puisque d'autres dossiers avec quasiment le même nom se copie sans problème.
Et surtout, ça fonctionnait parfaitement avant et je n'ai rien changé.
 
Mais j'ai un doute : est-il possible qu'un logiciel de bibliothèque musicale fasse le bazar la dedans ? du genre en modifiant les TAG, etc... ?

Essaie en ligne de commande déjà pour voir si ca vient du nom ou de l'application que tu utilises pour copier.

Essaie de virer les crochets dans le nom. Je sais, ça peut être très c×n, mais quand on sait que FFMpeg lui-même te dit « m××de » quand tu veux convertir des fichiers qui ont des « ! » dans leur noms, même en utilisant des « " » pour bien lui dire d’échapper pourtant ces caractères…

Je viens de tester ffmpeg avec un fichier qui a  un "!" dans son nom et pas de soucis.

Il faut utiliser des guillemets simples pour échapper les points d'exclamation, car dans les guillemets doubles ils risquent d'être sujets au développement de l'historique (history expansion).

 
J'ai un message d'erreur mais j'ai l'impression que c'est moi qui ne sait pas faire une copie en ligne de commande non ?  
 

 
On peut utiliser cp pour copier des dossiers ou cela ne fonctionne que pour des fichiers ?
 
edit : en mode graphique je fais un copier coller dans Caja en faisant glisser d'une fenêtre à l'autre.

 
Non ça bloque toujours.
edit : j'ai déjà tenté pas mal de modification au niveau du nom du dossier. Parfois ça fonctionne ( par exemple si je le renomme essai ) mais la plupart du temps j'ai beau tout modifier ça bloque. C'est totalement WTF comme souci...

cp n'est pas récursif par défaut, donc pour un dossier il faut utiliser -r comme te le dit l'OS
Pareil que pour rm, mais pas mv.

Eh oui, là quand même c'est explicite :

Par ailleurs il n'est jamais besoin de modifier les noms de répertoires, fichiers ou autres, avec quelque commande que ce soit. Il faut simplement bien échapper les caractères, par défaut avec des guillemets simples, ou avec des guillemets doubles lorsque le nom contient des guillemets simples.

 
Faut voir, avec certains logiciels mal codés ca peut etre utile...

C'est qu'ils ont été sacrément mal codés alors, car on est quand même là dans la base de la base, et je dirais qu'il vaudrait alors mieux modifier le logiciel en question (ou en utiliser un autre), que se soumettre à l'obligation de modifier ses noms de fichiers/répertoires.
En tout cas, ça ne saurait être le cas ni pour cp, ni pour ffmpeg.

On est d'accord
 
Juste que parfois changer un nom vite fait dans les 2 sens est plus rapide que de chercher l'erreur dans le code source ou trouver un logiciel alternatif. Pour un logiciel propriétaire ca permet aussi de prouver d'où vient le soucis.

Certes, ça peut arriver, et ça vaut probablement mieux que de rester devant son ordi à dire "non, je ne changerai pas mes noms de fichiers   "  

Donc voila j'ai ce message  
 

 
Et si je tente une copie d'un dossier qui déconne pas via cp -r ça roule, la copie se fait...

Tu as un espace entre le nom de ton fichier et l'apostrophe fermante dans ta ligne de commande, c'est pas ça le problème ?

Tu as raison il y a un espace vide à la fin des noms de certains dossiers, et c'est pour cela que ça bloque !

Merci à tous pour le coup de main en tout cas    
J'ai de l'occupation pour mes longues soirées d'hiver, il y a des espaces à enlever  

Il n'y a aucune raison à cela !

Tu n'aurais pas plutôt un problème de copier-coller ? Est-ce bien un espace à la fin du nom de répertoire ?

Oui c'est bien ça : j'ai vérifié en mode graphique -> il y a un petit espace vide à la fin du nom du dossier.
Je le supprime et le dossier peut alors se copier/coller sans souci...    
Et idem sur tous les autres dossiers qui coincent.
J'avoue que j'y comprend rien mais c'est bien l'explication  
 
edit : je copie depuis mon disque dur interne en Ext4 vers un disque dur externe en NTFS. Donc peut être une restriction de ce dernier ?
 
edit 2 : la copie inverse cad depuis un disque dur externe en NTFS vers mon disque dur interne en Ext4 ne semble pas bloquée par cet espace ! c'est donc encore plus WTF que prévu !

   
 
 
Non pas que ca change quoi que ce soit, mais au cas ou, je rajoute que le '-r' peut s'ajouter en debut, comme tu l'as fait, ou en fin de commande. Je me demande comment ca donne au milieu, je vais tenter tiens, je reviens.
.....
 
Ca fonctionne aussi!
 
 
 
Pour le renommage en ligne de commande je conseil rename (attention il y en a plusieurs j'utilise principalement celui qui vient dans util-linux) mais il y a aussi surement un en GUI pour ton DE. Sous Plasma j'utilisais krename a l'époque.
 
 
T'aurais du commencer par cela, le support en écriture du NTFS est loin d'être parfait, donc ca ne serait pas étonnant.
Comme dit kajoux l'espace ne devrait pas etre un probleme, du moins sous FS Linux.

Oui je sais mais malheureusement je ne peux pas mettre de l'Ext4 sur mes disques durs externes, vu qu'il n'est compatible qu'avec Linux et que tout mon entourage utilise Windows.

Ah d'accord, je pense qu'effectivement le problème vient de ntfs, ou en tout cas de la manière dont il est géré par ntfs-3g, car dans ses options on trouve :

Donc si cette option est active (par défaut ?) tu peux copier un fichier avec un espace à la fin depuis ntfs vers ext4 (dernière ligne de la citation ci-dessus) mais pas le créer (premier passage mis en gras).

Il existe des pilotes sous Windows pour lire EXT, btrfs, etc... mais bon c'est un peu moyen de devoir installer un pilote pour lire un DD, encore plus sur un ordinateur qui n'est pas a toi.
 
Si tu n'as pas besoin d'un truc trop complexe, peut-être que Fat32 ou exFat serait mieux.

Il me semble que c'est une restriction du format NTFS, pas de ntfs-3g

"C'est bon", avec une partition ntfs de test, j'obtiens bien moi aussi ce magnifique résultat :

Ce qui est bizarre, c'est que quand je regarde dans /etc/mtab pour inspecter le montage par défaut, je ne trouve pas trace de l'option windows_names

Mais bon, nul doute que le problème vient bien de là    
 

Ben je sais pas trop, vu qu'apparemment ntfs-3g semble prévoir que des fichiers se terminant par un espace puissent exister sur une partition ntfs…
Ce serait juste lui qui refuserait d'en créer… mais bon je connais pas assez ces trucs-là pour être très sûr de moi…

Voir un espace à la fin d'un nom de dossier c'est pas évident... heureusement que n0m1s a une bonne vue    
J'ai déjà eu des soucis avec des noms de fichiers sous Windows, en particulier avec la présence d'un ":" qui m'a fait bien des misères  
Depuis je conserve ceci en marque page    
https://assiste.com/Quels_sont_les_ [...] hiers.html

Pour être franc, je me demandais s'il n'y avait pas un caractère non-imprimable dans le nom de fichier donc je l'ai copié-collé sous vim (qui les affiche). Après ça, c'est un plugin qui colore les espaces en fin de lignes qui a fait le boulot

Il existe un overlay FS qui permet de pallier un peu a ce genre de soucis.

En gros tu le montes au dessus de ta partition MS, et quand tu copies l'overlay fait sa petite magie pour que les fichiers sur la nouvelle partition respectent bien les règles.

Je ne me rappele plus du nom la.
edit: posixovl peut-être.

Fat32 -> pas possible pour certains films de famille trop gros, vu la limite de 4Go    
Par contre exFat semble pas mal du tout, faudra que je le teste  

Oui, normalement c'est ce qu'il faudrait faire maintenant, apparemment : https://linux.developpez.com/actu/2 [...] indows-10/

Au pire tu divises le fichier quand tu le passes sur Fat32 (par exemple avec dd) et le regroupe sur Windows (la aucune idee comment).
Après c'est plus compliqué que le coup des noms de fichiers donc je ne suis pas convaincu.

Pour en avoir un peu plus le cœur net de tout ça, j'ai fait quelques recherches et tests.
Le coup de l'espace (ou du point) interdit en fin de nom de fichier/répertoire n'est donc pas une limitation de ntfs, mais de l'espace de nom win32 : https://stackoverflow.com/questions [...] 52#4123152
En pratique, dans une vm windows 7, ça fait peu de différence, puisqu'on ne peut pas créer graphiquement un fichier dont le nom se terminerait par un espace (enfin on peut, mais l'espace est viré automatiquement).
En revanche, en ligne de commande, il est possible de faire (en s'inspirant de ce qui est dit dans le lien donné ci-dessus)

Et là, miracle, un fichier dont le nom est 'test ' est bien créé.
 
Si on repasse ensuite sous linux, on a bien

et comme indiqué dans le man de ntfs-3g (cf. mon commentaire plus haut), il est possible de lire ce fichier, et de le copier :

Voilà voilà  
 
PS : comme cette limitation est indépendante du système de fichiers, mais est propre à l'espace de noms win32, elle aura lieu sous windows aussi bien avec du exfat qu'avec du ntfs (testé sous windows 7).
Néanmoins, sous linux, exfat-fuse ne refuse pas de créer un fichier avec un espace à la fin du nom comme le fait ntfs-3g.
Donc, si cette limitation n'a plus lieu sous windows 10 aujourd'hui, comme un précédent post de Mobilis semble le suggérer, il serait finalement bien préférable d'utiliser exfat à la place de ntfs.

Je vais faire passer mon disque dur externe de 320 Go sur exFat et je vous tiens au courant  

Je suis en exFat sur mes disques, c'est un poil lent des fois. Ça c'est le seul truc qui flanche sous Linux, les transferts usb ça a jamais été performant. J'ai jamais osé passer mes disques durs externes en ext4, je me demandes si ça améliorerait pas les performances plutôt que de s'entêter avec du fat32 ou du exFat ...
Y-aurait-il des retours dessus ?

Il faut faire attention, je crois que les pilotes Ext pour Windows ne fonctionnent plus sous Win10.  
A confirmer.

On dirait qu'il y a toujours des solutions avec W10:
 
https://www.paragon-software.com/home/linuxfs-windows/
 
http://www.ext2fsd.com/