I have looked at the three threads:

1. topic-26899
 LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt 
is asking for trouble! Spaces, accented characters, and worst, the embedded ' . The user was not very clued up, and your final ingenious solution worked:
 $ rm "$(ls -1 | grep FABRICATION)"
Doing this more conventionally with escapes & double quotes might have worked; the thread is bogged down by necessarily complicated syntax.
I might try this here to see what happens, if there *is* a bug.

2. topic-26958
 E_20190121_774_v1.jpg which looks a sensible filename. But here, 75/568 files could not be deleted. Unclear whether they were all in the same directory
/run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21.anc/
Again this thread (still up in the air) gets bogged down in syntax.

But I wonder whether *this* is important:
 Le 09/12/2019 à 14h46
"le fichier est bien existant E_20190121_774_v1.jpg, même si ce n'est de toute évidence plus une photo puisqu'il ne pèse que 9.1 Kb (au lieu de 5.4 Go)."
 suggests a corruption somewhere. Worth trying fsck, CAREFULLY, check only.

The full directory listing Le 09/12/2019 à 16h42 looks OK (but odd, with all files executable, and many .jpg.xmp). I imagine these are the 75 that do not go.
BTW I did not see * in any filenames, only appended to them (executable, as somebody pointed out).
I did not notice any attempt to delete them differently, e.g. by trying one then several at a time from the end. I am wondering whether the iffy file above is blocking access to the later ones.

Since all the files are readable, has yet been tried moving them all (say except the first one) to another directory, and deleting them from there? Or doing (from the next higher directory) :
 $ rm -rf 2019-01-21.anc/

3. topic-27145
 20190805-Santa Pola Puerto/
was just a basic question of spaces in the directory name, resolved
 Le 14/01/2020 à 19h50
"tu met "20190805-Santa Pola Puerto" entre guillemets"
 Le 14/01/2020 à 20h47
"j'ai fait comme tu dis ça a marché merci"
Fixed.

Can you and the other forum stalwarts take every opportunity to *discourage* at least the use of spaces & accented letters in filenames; and certainly anything more esoteric. It just complicate life, and necessitates careful use of enclosing quotes in commands - to emphasise.

CC: (none) => lewyssmith

(In reply to Lewis Smith from comment #1)
> I have looked at the three threads:
> 
> 1. topic-26899
>  LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt 
> is asking for trouble! Spaces, accented characters, and worst, the embedded
> ' .
Totally agree ! I don't know why people are looking for trouble... I even read someone on internet struggling against softwares that don't manage such charset as "it works well in javascript, we are in 2020". (no joke...)

> The user was not very clued up, and your final ingenious solution worked:
>  $ rm "$(ls -1 | grep FABRICATION)"
> Doing this more conventionally with escapes & double quotes might have
> worked; the thread is bogged down by necessarily complicated syntax.
> I might try this here to see what happens, if there *is* a bug.

He tries with double quote but didn't worked (28/11/2019 at 15h12) :
>mv "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt" lesetapes.odt
>mv: impossible d'évaluer "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt": Aucun fichier ou dossier de ce type

He also tries with escap char, same post :
>[root@localhost edouard]# rm LES\ ÉTAPES\ DE\ FABRICATION\ D\'UN\ IMPRIMÉ.odt
>rm: impossible de supprimer "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt": Aucun fichier ou dossier de ce type

Autocompletions after starting with "LES" didn't worked neighter.
> C’est là que j’ai ouvert un terminal avec F4 et tapé « rm LES ». Mais ensuite la touche « Tab » n’a rien donné.
(TR : It is there that I opened a terminal with [F4] and typed "rm LES". But after, the [TAB] key didn't give anything)
So... Maybe his filename start with the double quote char, or with two simple quote, or the something else... We don't know unfortunately.

The thing is, (it is not written, but I guess it was too trivial to mention it) the GUI button "delete" on dolphin refuses to delete. (But it is only a supposition... Who will fight on terminal before trying on the GUI ? In fact he mentions "pressing [Delete] inside Dolphin". So in a way, there is a bug in Dolphin.

> 2. topic-26958
>  E_20190121_774_v1.jpg which looks a sensible filename. But here, 75/568
> files could not be deleted. Unclear whether they were all in the same
> directory
> /run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21.anc/
> Again this thread (still up in the air) gets bogged down in syntax.
> 
> But I wonder whether *this* is important:
>  Le 09/12/2019 à 14h46
> "le fichier est bien existant E_20190121_774_v1.jpg, même si ce n'est de
> toute évidence plus une photo puisqu'il ne pèse que 9.1 Kb (au lieu de 5.4
> Go)."
>  suggests a corruption somewhere. Worth trying fsck, CAREFULLY, check only.
Here there is something "weird", like a file permutation :
>> 85928 12K -rwxrwxrwx 1 dan dan 9,2K oct. 27 21:15 /run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21_anc/E_20190121_774_v1.jpg*
>> 85929 9,4M -rwxrwxrwx 1 dan dan 9,4M oct. 27 21:15 /run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21_anc/E_20190121_774_v1.jpg.xmp*
The .xmp file is 9.4 MB, and the .jpg is 9.2 KB. All other files in the directory are ~10 MB for .jpg and ~10 KB for .xmp (I guess a kind of xml file).
 
> The full directory listing Le 09/12/2019 à 16h42 looks OK (but odd, with all
> files executable, and many .jpg.xmp). I imagine these are the 75 that do not
> go.
> BTW I did not see * in any filenames, only appended to them (executable, as
> somebody pointed out).
You are correct ! I'm sorry, I wrote * in this bug report, even if on the topic I correct someone telling the * is in the file name :
https://www.mageialinux-online.org/forum/topic-26958-1+fichiers-insupprimables-sur-dd-externe.php#m261507
>> papoteur : Serait-ce que * dans jpg* ferait partie du nom ?
( TR : Is the * in jpg* a part of the name ? )
> Jybz : C'est le formatage de ls -lisah qui indique par le * que le fichier est exécutable. 
( TR : it is the formatted output of ls -lisah that indicates with the * that the file is executable )
One month and I fell myself in the same trappe...

> I did not notice any attempt to delete them differently, e.g. by trying one
> then several at a time from the end. I am wondering whether the iffy file
> above is blocking access to the later ones.
> 
> Since all the files are readable, has yet been tried moving them all (say
> except the first one) to another directory, and deleting them from there? Or
> doing (from the next higher directory) :
>  $ rm -rf 2019-01-21.anc/
Yes, we need further investigation, but he isn't ansewring anymore.
He tries to remove the file :
> rm /run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21.anc/E_20190121_774_v1.jpg'
> rm : supprimer fichier '/run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21.anc/E_20190121_774_v1.jpg' ? o
> rm: impossible de supprimer '/run/media/dan/Transcend/Photos/Ap-2018/2019/2019-01/2019-01-21.anc/E_20190121_774_v1.jpg': Aucun fichier ou dossier de ce type
the rm command finds the file, but when trying to remove it, it doesn't find again.

Probably a data corruption, I will suggest the fsck cmd. But the any jpg with was never 5GB as he wrote, maybe the entire directory...


> 3. topic-27145
>  20190805-Santa Pola Puerto/
> was just a basic question of spaces in the directory name, resolved
>  Le 14/01/2020 à 19h50
> "tu met "20190805-Santa Pola Puerto" entre guillemets"
>  Le 14/01/2020 à 20h47
> "j'ai fait comme tu dis ça a marché merci"
> Fixed.
> 
> Can you and the other forum stalwarts take every opportunity to *discourage*
> at least the use of spaces & accented letters in filenames; and certainly
> anything more esoteric. It just complicate life, and necessitates careful
> use of enclosing quotes in commands - to emphasise.
Unfortunately, it is a lobby. As long as MS removes the file extension, as long as "we" use labels on file name like "Bureau" for "Desktop" /home/${USER}/Desktop , we train people to use more esoteric char in file name...
But I totally agree with you. Generally, my filenames are formatted :
0_FileName.extension1.extension2
or
2020-01-16_FileName.ext
But I can't to it for others ! :D

I will play with the first file
 LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt
when I have time.
For the multiple deletion failures, you could offer some of my suggestions from comment 1 even if he is not replying, for others to see. The important test is to try and delete a (or more if that works) file later in the directory. That would be easy to try. To see at worst that they all throw the same error.

We can do nothing at this end. I would be happy to join the thread *if* I had some time...

(In reply to Lewis Smith from comment #3)
> I will play with the first file
>  LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt
> when I have time.
Could do nothing wrong. Used a real .odt filer as the starting point. From the console:
 $ ls -l
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016 cycleRockies3.odt

 $ mv cycleRockies3.odt "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016 "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"

 $ mv "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt" cycleRockies3.odt
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016 cycleRockies3.odt

 $ cp cycleRockies3.odt "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016  cycleRockies3.odt
-rw-r--r-- 1 lewis lewis 140042 Ion  17 18:22 "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"

 $ rm "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"
rm: remove regular file "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"? y
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016 cycleRockies3.odt

 $ cp cycleRockies3.odt LES\ ÉTAPES\ DE\ FABRICATION\ D\'UN\ IMPRIMÉ.odt
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016  cycleRockies3.odt
-rw-r--r-- 1 lewis lewis 140042 Ion  17 18:24 "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"

 $ mv LES\ ÉTAPES\ DE\ FABRICATION\ D\'UN\ IMPRIMÉ.odt copy.odt
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Ion  17 18:24 copy.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016 cycleRockies3.odt

 $ mv copy.odt LES\ ÉTAPES\ DE\ FABRICATION\ D\'UN\ IMPRIMÉ.odt
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016  cycleRockies3.odt
-rw-r--r-- 1 lewis lewis 140042 Ion  17 18:24 "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"

 $ rm LES\ ÉTAPES\ DE\ FABRICATION\ D\'UN\ IMPRIMÉ.odt
rm: remove regular file "LES ÉTAPES DE FABRICATION D'UN IMPRIMÉ.odt"? y
 $ ls -l *.odt
-rw-r--r-- 1 lewis lewis 140042 Meh   1  2016 cycleRockies3.odt

The following comments show screenshots re Dolphin with this file.
In short, I could find nothing wrong if the rules were obeyed: " or \

Created attachment 11462 [details]
Dolphin display showing the file in $HOME

This shows the file being correctly displayed normally in Dolphin.

Created attachment 11463 [details]
Screenshot of Dolphin after deleting the file

Shows the home directory displayed by Dolphin after 'Del' the file, which went with no hassle.

Created attachment 11464 [details]
Dolphin display of the file in poubelle (trash) after 'Del' it

The Dolphin display of trash after deleting the file; showing it is here, correctly. I was even able to Restore it.

You can put in the thread:
 https://www.mageialinux-online.org/forum/topic-26899.php
a reference to this bug, say:
 https://bugs.mageia.org/show_bug.cgi?id=26076#c4

I did these tests under Mate; I do not want to re-try under Plasma, but there might be a problem there. Closing in the meantime; re-open if necessary.

Resolution: (none) => WORKSFORME
Status: NEW => RESOLVED

Thank you Lewis Smith,

A new user find some trouble with rsync and some file name,
https://www.mageialinux-online.org/forum/topic-27270+grsync-erreurs.php
like:
>rsync: mkstemp "/run/media/louis/Sauvegarde_Louis/Sauvegarde/louis/.java/fonts/1.8.0_212/.fcinfo-1-localhost-"Mageia"-7-fr.properties.ONK41P" failed: Invalid argument (22)

I asked to type :
> ls -lisah /run/media/louis/Sauvegarde_Louis/Sauvegarde/louis/.local/share/okular/docdata/.48* | xxd >$HOME/analyse.txt
I hope we can find some extra char...

> Le 20/02/2020 à 10h11
> Je suis d'acis de supprimer les " du nom. 
Agreed. These pathnames are mindblowing. How did the "Mageia" get into them? The opening " of *this* string will close the opening " of the entire pathname, chopping it into two invalid bits.

Another doubtful aspect is the use of the overall surrounding " when the enclosed filename contains characters special to the shell which can be interpolated within them. Try surrounding ' instead.

See what gets displayed when you 'ls' (no need for more) the path at different levels. Try starting with the highest, and add a level until something does not work. That might give a clue.