Haiku considers OpenXML files (docx, pptx, xlsx) to be zip files

phoudoin · July 1, 2026, 7:47am

Any, I wont bet on it.
But most, yes.

Did the file type was previously identified already?
Because the MIME sniffing doesn’t run on files which have already a MIME type, even if it was guessed a wrong type.

To enforce a new, fresh, MIME guessing:

rmattr BEOS:TYPE <path_to_file>
mimeset -f <path_to_file>

For a whole directory content, just use “<path_to_dir>/*” as argument.

Or via Identify from Tracker contextual menu. But first the file type must be removed, if any.

If it still doesn’t work, open your docx with DiskProbe and search for “word/” string pattern and report here the file offset of first match. If there is one…

phoudoin · July 1, 2026, 7:51am

Wait, did the file is on a non BFS volume?

KitsunePrefecture · July 1, 2026, 1:24pm

I followed the instructions :

   user  ~    08:09    cd /SANDSK256GO/OtherS/DoQ/DL/Fontos/MED/
   user  /SANDSK256GO/OtherS/DoQ/DL/Fontos/MED    14:51    ls
2025_08_12__Labor_vizsgálati_eredmények.pdf  jarobeteg_szfvarelojegyzes_2.docx
   user  /SANDSK256GO/OtherS/DoQ/DL/Fontos/MED    14:51    rmattr BEOS:TYPE jarobeteg_szfvarelojegyzes_2.docx
   user  /SANDSK256GO/OtherS/DoQ/DL/Fontos/MED    14:52    mimeset -f jarobeteg_szfvarelojegyzes_2.docx
   user  /SANDSK256GO/OtherS/DoQ/DL/Fontos/MED    14:54    catattr BEOS:TYPE jarobeteg_szfvarelojegyzes_2.docx
jarobeteg_szfvarelojegyzes_2.docx : 'MIMS' : application/vnd.openxmlformats-officedocument.wordprocessingml.document
   user  /SANDSK256GO/OtherS/DoQ/DL/Fontos/MED    14:55   

Then in Tracker window (WOW, I must not do anything .. however the folder window was open already on another workspace .. to refresh the view status, it contained the new value !)

(I’ve just adjusted the lenght of the field to fit to the new value - before the screenshot !)

"the proof of the pudding is in the eating !.. "

Finally it worked !

Thanks for your patch !

So, I must change the filetype for all OpenXML files manually that dragged/downloaded already to a BFS filesystem .. before hrev59812 ?

KitsunePrefecture · July 1, 2026, 2:37pm

No, in that case I tried to open a file from a BFS volume, as I thought about it as this treat how would it be working in Haiku …

/SANDSK256GO is a full BFS volume on a thumbdrive.

I plugged in an exfat thumbrive – mounted read-only.

(I have CVs there which should be .docx files I do not have EXCEL files so much - saved. I should might find some on an older drive that can contain some of templates from my IT guy era. I had not felt to store infos in excel files for personal stuff.)

Well, in this case detection went well, I assume as on non-BFS volume Tracker fallback to extensions.

but Libreoffice could not open the file

as I have HUN localization - with non-English latin letters - folder/file names there,

that Haiku does not treat the same way as Windows/Linux does -

it is experience, not assumption !

You can see it in the error message window,

Cannot handle ../Önéletrajz/.. folder which was created on Windows earlier.

(that means autobiography, in Hungarian - we use the same word for CV as well, we do not have an another word to differentiate this condensed and work related type of autobiography, we may add ‘szakmai’ - so ‘professional’ autobiography if we want to differentiate)

Unicode on Windows/Linux and unicode on Haiku works a little different by default.

It was the same problem on Linux as well in the early 2000s years, but since then it changed. Not in all cases, but mostly.

Recently on one forum entry or in a Haiku ticket I met such terms as Unicode 8 and Unicode 16.

Haiku possibly use UTF8 by default, meanwhile Windows uses UTF16 … and may some Linux distros which ones wants to enable to use folders/files created by Windows – adapted to use UTF16 by default.

( Source Google Search to Unicode 8 Unicode 16 )

I am not sure, just guessing.

EDIT :

I copied the file - by dragging - to Desktop, so the filepath now was understandable for Haiku and the file was ‘Word document’ by type and opened in LibreOffice as expected.

So for issue resolution :

- → Haiku’s Terminal/Tracker should treat at least FAT/EXFAT/NTFS drives as UTF16 by default to work with their localized content – if my guessing is right.

madmax · July 1, 2026, 3:08pm

Yes. If you have set the type of a file against the system guess, you don’t want the system to change it. And there’s no way to know if you set a type manually or it was guessed.

If you don’t mind about that and want to do it automatically for all the files that currently have zip type, I guess you can do something like this (untested, and notice I’m using -F, not -f):
query 'size>0 && BEOS:TYPE="application/zip"' | mimeset -F '@'

That will be slow. If you have the type indexed, which most probably you don’t, it will be much faster and you can leave the size test out. Add -a option to query if you want to visit all volumes. Most probably you only care about the files under home or maybe a few directories, and it will be better to use find by name, something like find ~ -iname '*.docx' -o -iname '*.xlsx' | mimeset -F '@'

Maybe not exactly right, but yes, encoding issue. That’s known, and there are even patches in gerrit that seem to be about it.

KitsunePrefecture · July 1, 2026, 4:40pm

Thank you for the detailed answer.

I tried out the commands. I have BFS volumes which created with indexing capabilities.

Well, this way query command was fast as you wrote. Of course I just issued without mimeset command and using time as well to see how slow it is.

I usually use find command selecting the directory to fit to my search conditions.

In both cases the result was small, so even I can modify the files manually.

However query -a command altogether the exfat drive – despite the find command with same conditions – caused that

Haiku crashed with ‘General Protection Failure’ and there were the thread 40 stack strace mentioned “usb_disk scheduler 3”.

Not cont or exit command helped to get out of KDL prompt, but reboot only.

So query -a is bold movement if all drives which mounted USB disks - with several partitons - especially those non-BFS filesystems on them, or the fat/exfat partition were not tolerated by query in this case … I dunno.

Otherwise the SSD in the machine is for Linux Mint only. I installed it onto ext4 however the recommendation was btrfs in the Mint installer. This enabled to mount on Haiku and get Haiku/Linux cross-related files from the Linux Desktop folder. If I choose btrfs, then it is not usable actually from Haiku - even that btrfs has snapshot feature. I rather use an external btrfs drive to backup/archive.