Strange occurence with File Managers

[manyroads]

If you are up to taking a backup before... you might try to detoxify your filenames and folders. There are probably many ways to take care of the issue but here's a guide (note:I have not tried this approach, I had to do it manually a couple of dozen years ago when I encountered something similar to what you described above):

https://linuxconfig.org/clean-up-filena ... ne-utility

Edit: FWIW my files and folders had some hidden character cruff. I have no idea how the cruff got there.

[ceejayemm]

@fehlix
Your suggestion in #30 seems to have no effect. I have made the change and logged out and back in again, no change.

While perusing this subject I came across this:

https://bugs.kde.org/show_bug.cgi?id=305136

which relates to a similar ongoing problem with KDE/Firefox but also seems synonymous with this problem. I must say however I do not follow most of what they are discussing but it seems to suggest that a possible cause is the file mimeinfo.cache not being actioned correctly (?) by KDE - if I am reading it right. I don't understand it enough to even begin to consider any changes but may be others here might ?

Similarly, @CharlesV, in #22 notes:

https://forum.xfce.org/viewtopic.php?id=17257

which has similarities so it seems I am not so much on my own as I thought. Neither article seems, as yet, to have come up with a definitive solution. I have mentioned this before but it does seem odd that both the XFCE Laptop and the KDE Plasma desktop both suffer from exactly the same issue and from around the same time. May be it goes a bit deeper than XFCE and KDE ?

@manyroads - thanks for your suggestion, I have had a look but I don't think this applies as it now seems my problem is very specific to .js/.json files. But thanks.

Regards.

Chris

[CharlesV]

@ceejayemm and if you turn off thumbnails in thunar this issue stops?

Do you know where that tree.cm.json file came from?
The contents of it look like they were created from some image editor ? Possibly just leave it (and the other files) named differently or moved to a 'bad' folder and see if this keeps the issue resolved?

[fehlix]

@fehlix
Your suggestion in #30 seems to have no effect. I have made the change and logged out and back in again, no change.

Hmm ... , are you saying both commands

Code: Select all

gio mime  application/json

and

Code: Select all

xdg-mime query default application/json

give you still two different defaults?

Perhaps show the result again when running the commands.
Are thos .json files still seen as mimetype "application/json"?
E.g. Does this

Code: Select all

xdg-mime query filetype  data1.json

gives "application/json" ?
B/c mimetype detection is a "hybrid" method of weighted file-extension plus content.
So any installed app can change the weight, which may give another mimetype.

The one file you send "data1.json" is indeed a bit special b/c that is one very long 57K sized line
without a linefeed at the end.
May be try this experiment on the command line:
create a new directory copy a modified data2.json,

Code: Select all

python3 -mjson.tool < data1.json > data2.json

This would add some linefeeds, and would make the json file viewable by any text-editor.
Do you still have an issue with the modified data2.json?
If not, how many of such json files do you have?
PS: adjusted the python line by reading from stdin (with "<") , otherwise the read-line limit creates an invalid json.

[ceejayemm]

A bit of background might help. I migrated from Windows 10 to MX Linux 21 just about 2 years ago and then to MX23 when this was released. I brought across some files from Windows that I was working on at the time, one of which was a photo album project generated on Windows by a product called JAlbum (jalbum.net). The .json files, uploaded as examples for this issue, where from this project. I wasn't intending to do anything with this stuff, it happened to be copied with a whole pile of other stuff. So it has sat on my laptop for the best part of 2 years not causing any problems until I had cause to report this issue on March 25th and we have subsequently narrowed it down to a problem with .json files and latterly .js files too. The .js file I uploaded came from a ZenPhoto (zenphoto.org) installation kit downloaded directly from their website to my now MX Linux laptop, the .js file I chose to upload was an arbitrary selection from several in that kit. I was pure chance I chose these files to be uploaded as examples.

@fehlix I have rechecked the commands you asked me to run in #27, the output being:

Code: Select all

ceejayemm@cmlaptop1:~
$ gio mime  application/json
Default application for “application/json”: featherpad.desktop
Registered applications:
	featherpad.desktop
	formiko-vim.desktop
	formiko.desktop
	geany.desktop
	xfce4-terminal-emulator.desktop
	code.desktop
	libreoffice-writer.desktop
	nano.desktop
	org.kde.kate.desktop
	org.kde.kwrite.desktop
Recommended applications:
	featherpad.desktop
	formiko-vim.desktop
	formiko.desktop

and

Code: Select all

ceejayemm@cmlaptop1:~
$ xdg-mime query default application/json
featherpad.desktop

I am not sure what the comment #32 was about, probably because I missed the output from the command. Rerunning the command again gives:

Code: Select all

ceejayemm@cmlaptop1:~
$ gio mime application/json featherpad.desktop
Set featherpad.desktop as the default for application/json

Checking on the data1.json file also requested in #32 gives:

Code: Select all

ceejayemm@cmlaptop1:~/test1
$ xdg-mime query filetype  data1.json
Segmentation fault

As requested, I then created a new folder (test2) and copied data1.json to it before running the python script to correct the formatting of the content.

Code: Select all

ceejayemm@cmlaptop1:~/test2
$ python3 -mjson.tool < data1.json > data2.json

The new file was checked:

Code: Select all

ceejayemm@cmlaptop1:~/test2
$ xdg-mime query filetype  data2.json
Segmentation fault

It would appear that it is the CONTENT (any content) of the file which causes the problem. Somewhere above somebody asked me to turn off the thumbnail previews in Thunar. To do this I set 'Show Thumbnails' to 'Never' and 'Only show thumbnails for files smaller than' set to 512kb. Is this enough to turn off previews ? If not can somebody tell me what else I need to do please ?

As noted above the problem seems to be specifically associated with .js or .json files and further seems to relates to those files with content. Empty .js or .json files do not seem to cause this problem but as soon as they do have content then the problem starts. As also noted before, it is not only Thunar on XFCE which exhibit these issues but the delivered version on Dolphin on KDE as well. Later FlatPak versions of Dolphin installed on XFCE or KDE do NOT seem to exhibit a problem.

I hope this helps

Chris

[CharlesV]

Interestingly ... both data1.json and all.min.js files are over 2880 and 4237 lines of code (respectively) when you run them through a formatter.

But these have VERY VERY long lines when looked at before formatting.

Might be interesting to format them and then save the new formatted versions and see if that makes any difference.
json formatter: https://jsonformatter.org/
js formatter: https://codebeautify.org/jsviewer/#

[m_pav]

Wow, what a rigmerole, and its not the first time I've seen this because I have encountered it myself, thankfully, the offending file was easily found and sorted, but it was ~10 years or so back, possibly more. IIRC, I recorded my find it either here or in the old WW Mepis Forums.

The issue I experienced had a ringing familiarity with something you've discovered in the last few responses in this thread, the file was created in Windows as the output of a particular application and it too caused all Linux File Managers to act as if they were killed by the Crtl + Alt + Esc "skull & crossbones" process killer.

I had no proof, but I have a suspicion the issue stemmed from touching a file created by a Windows app encoded with the ASCII character set that had a particular non-alpha-numeric character in the file name, while we operate on the UTF character set. If I recall correctly, the offending character was represented in Linux as something like a chinese hyroglyph character, but in Windows it was simply a non alpha-numeric character.

I connected the customers drive via USB to a Windows machine I kept on hand for doing virus scans and it came up clean, the file name looked normal and it had a character in its name that resembles the type one creates when using one of the Alt keyboard sequences. I examined the file using a hex editor and indeed at the beginning of the file where its name is held, the Alt Character could have easily triggered a kill process to a Linux host so I changed that one character in the file name to something simpler and when back in Linux, the file copied without fuss.

As it turns out, all my work was for nought as the customer had no further need for the files content and I had never come across it again, that is until I read through all you've bee through.

Could it be that simple for you too, and really, would you have any further use of it now that you've been in the camp for 2 years running? ASCII encoding of file names being read in a system that uses UTF character sets that could potentially be interpreted as kill signals or become a fault that causes a process to die unexpectedly?

[fehlix]

I am not sure what the comment #32 was about, probably because I missed the output from the command. Rerunning the command again gives:
Checking on the data1.json file also requested in #32 gives:

Code: Select all

ceejayemm@cmlaptop1:~/test1
$ xdg-mime query filetype  data1.json
Segmentation fault

Great, we have a show stopper. So something with you mime stuff is different.

As requested, I then created a new folder (test2) and copied data1.json to it before running the python script to correct the formatting of the content.

Code: Select all

ceejayemm@cmlaptop1:~/test2
$ python3 -mjson.tool < data1.json > data2.json

The new file was checked:

Code: Select all

ceejayemm@cmlaptop1:~/test2
$ xdg-mime query filetype  data2.json
Segmentation fault

OK, so let' make sure the added linefeeds, made it into the "beautfied" json.
Could you openwith featehrpad ( or geany) the data2.json normally.
And run this little check:
Line count of original data1.json and re-formatted data2.json

Code: Select all

wc -l data1.json data2.json 
     0 data1.json
  2880 data2.json

"wc -l" counts 0 lines b/c the one line does not end with the "line-feed".
So you should have 2880 lines within the new data2.json , which is a normal valid json-file.
and gives here normal mimetype:

Code: Select all

xdg-mime query filetype  data2.json
application/json

At least here running in MX23.2-Xfce, the only issue I can see is the one 57k-long line,
for some tools which may read line-by-line and get a out-of line-buffer error.
So may guess something within you mime-datebase was adjusted,
to make filetype query fail, hence Thunar would also fail.

[ceejayemm]

@fehlix
I can't open any of the test files in Featherpad or Geany by using the File / Open dialogues. After navigating to the relevant folder in File/Open FeatherPad just closes immediately it finds these files. If however, from the CLI, I issue the command:

featherpad data2.json

the file will open and it looks ok, formatted as you would expect. Also:

Code: Select all

ceejayemm@cmlaptop1:~/test2
$ wc -l data1.json data2.json 
     0 data1.json
  2880 data2.json
  2880 total

I am not sure if this issue does relate to my mime database setup but rather is it a deeper problem with the way in which files are opened in applications as shown by the FeatherPad/Geany example shown above. I also think the size of the file is a red herring. I don't know much about .js/.json files so I went to https://www.w3schools.com/js and used some of their very simple examples to create some very basic files - small_file.js and small_file.json - in a new folder. Thunar cannot open this new folder with these files in it. I have attached these files so you can how simple they are.

small_files.zip

Both my laptop (MX Linux 23.2 XFCE) and desktop (MX Linux 23.2 KDE) started displaying this problem on or around March 25th this year. This might point to some sort of update which happened to both these machines on/around that date. Whatever happened seems to have affected the way in which .js/.json files in particular are opened in various applications. I do not seem to have this problem with any other file types (so far anyway).

Chris

[oops]

If you are up to taking a backup before... you might try to detoxify your filenames and folders. There are probably many ways to take care of the issue but here's a guide (note:I have not tried this approach, I had to do it manually a couple of dozen years ago when I encountered something similar to what you described above):

https://linuxconfig.org/clean-up-filena ... ne-utility

Edit: FWIW my files and folders had some hidden character cruff. I have no idea how the cruff got there.

I did' nt know detox, this can be useful .

When I have a potential inode issue on ext partition, I often try to do first a : "e2fsck -Dyf /dev/sdaxx"