renaming a .desktop file that contains pipe | will cause it to disappear until you exit and reenter the folder on internal secondary drive mounted in NTFS.

[taltamir]

Distribution

Mint 21.3

Package version

nemo 6.0.2

Frequency

over 90% of the time. very rarely it manages to rename without disappearing the file. but then i try again on the second file and it is disappearing.

Bug description

renaming a .desktop file that contains pipe | will cause it to disappear until you exit and renter the folder on internal secondary drive mounted in NTFS. I had initially thought they are deleted, but they are still there and just require a refresh via exiting and reentering.

oddly enough .txt files do not have this issue.

Steps to reproduce

1. mount an NTFS drive using fstab to /mnt/d/
2. open nemo to any directory in that drive. ex: /mnt/d/
3. right click and create a new text file. name it test|test.desktop
4. select that file and rename it to test2|test.desktop
   90%+ chance that the file will disappear.

alternative steps to reproduce

1. mount an NTFS drive using fstab to /mnt/d/
2. open nemo to any directory in that drive. ex: /mnt/d/
3. in firefox. click on the lock icon to the left of the url and drag it to /mnt/d/ in nemo
4. select the link file created and rename it to test|test
5. select test|test and rename it to test2|test
   90%+ chance that the file will disappear.

unexpected exclusions

Not all file extensions trigger this bug. I have tested several different options and so far I found two methods to trigger it. but several that do not.
Triggers the bug:
text files that I add a .desktop to
link files created by firefox or brave when drag and dropping a url to nemo that have a hidden .desktop

Does not trigger the bug:
text file without extension
text file with .exe extension
text file with .com extension
text file with .txt extension

Expected behavior

I expected the file to still show up in nemo
or for nemo to forbid it and force me to choose a different name / automatically drop that character

Additional information

A. The file is not really gone. you can leave and come back and it will be there

B. there is a very small chance (less than 1 in 10) for the bug to not occur. in several dozen tests I had this happen twice.

C. My fstab info for mounting that ntfs drive is:
UUID="redacted" /mnt/d auto uid=username,nodev,nofail,x-gvfs-show 0 2

[taltamir]

While testing it, I did not notice I was only testing in my mounted NTFS drive (internal drive).
Also, thinking about it, it can be reproduced by creating a new empty text file and renaming it to .desktop
I will adjust the bug report momentarily.

---

ok so, on further testing. i thought the file gets deleted. but in fact it just becomes temporarily invisible. if you navigate away from that folder and than navigate back into it, it will reappear under the new name.

oddly enough, using a .txt file does NOT cause this error

---

I should note that I am not just one day deciding "hey, I want to make files with | in the name".
rather, a bunch of websites use | in their page name. when you drag and drop the url from any browser into nemo it creates a link file to that page. and that link file will have a | in it if the website owner decided to put | in it's name.

example site:
https://www.thesaurus.com/e/grammar/pipe-symbol/
or actually this very page
#3392
if I drag that url to /mnt/d/ I get a file named
Link to renaming a .desktop file that contains pipe | will cause it to disappear until you exit and renter the folder on internal secondary drive mounted in NTFS. · Issue #3392 · linuxmint/nemo
which contains | and triggers this bug

[taltamir]

reopened. i did not mean to close it. that was an accident

---

my system
https://termbin.com/w283

---

I seem to have stumbled into a potentially related bug. or maybe unrelated. i am unsure.

if I go to this page
https://www.thesaurus.com/e/grammar/pipe-symbol/
I can drag the URL to either /home or /mnt/d and it will create a link

if instead I go to
#3392
I can drag the URL to /mnt/d and it will create a link.
but if I try to drag it to /home or anywhere under /home it will do nothing. failing to create the link.
/home is in a btrfs drive IIRC. it is encrypted... but currently unlocked.

I tried this using both firefox and brave for both addresses for all locations.

[leigh123linux]

Unsubscribed from this issue due to the amount of spam email, 9 emails isn't reasonable!!!!!