Mp3 files on linux partition showing up as type application

So, I installed 52300 to my multi-boot desktop’s hard drive and booted up into Haiku with no problems. I have some mp3 music files in some folders on my linux partition that I have been trying to organize use a tagging program called kid3. When I mount the partition and navigate to the folders, most of the files are showing up as type application. In a few instances there are very similar files, same artist, same title maybe different lengths and/or different bit rates but one is recognized as an audio file while the icon for the other is the application icon.

I can’t readily discern why this is happening since “get info” displays all the right attributes except for the type. One thing I noticed in one of the folders is that four of the files that were recognized as audio files were files I had added recently. The bulk of the files were copied from someone eles’s computer.

I got a clue to the solution by just double clicking on the file to open it. A message popped up “Cannot open [filename}. The file is mistakenly marked as executable, Should this be fixed?”. Clicking on the “Proceed” button resulted in a message stating that the file cannot be modified because it is a read only file system. If I mounted the linux partition read/write clicking on the “Proceed” button resulted in the file being opened in Media Player as expected.

I booted up linux on the computer and sure enough all the files that Haiku was flagging as type application were marked as executable. Removing the execute bit fixed the issue. I was able to use Nautilus (the Ubuntu GUI file manager) by selecting all the files in the folder, going to the permissions tab and then selecting and de-selecting the “Execute” check box. On viewing the execute tab initially, the check box was coloured and had a “-” inside it, I assume this indicates that some of the selected files are marked as executable. Selecting the box resulted in a check being displayed in the box (all selected files executable) and subsequent de-selecting the check box resulted in the box having nothing in it (no selected files executable).

Very easy and quick fix. Didn’t even have to use the command line!

1 Like

I wonder how/why the executable bit got set on those files in the first place…

BTW, I had some bad experiences mounting ext2/3 partitions writable in the past. Linux regularly demanded to run fsck on the next boot-up. Since then I only ever mount ext partition read-only.
It’s been a while, so things may have improved, but I kinda doubt it…

executable bit are usually left when copying from fat/ntfs to ext

Hmm… is that a bug or feature? :slight_smile:

at least on my Arch environment it is a feature, all files and directories on those filesystems are mounted with chmod 777 and when copied to ext it preserves those permissions no matter the file or dir.

Yes, since FAT and NTFS can’t store the “executable” permission, Linux will assume all files are executable. This is similar to our FAT and NTFS drivers faking MIME attributes for some files, so that you get a minimal level of functionality.

As for EXT volumes, our driver currently implement ext2 writing, maybe some of ext3 but I’m not even sure, and certainly not all of ext4.
Writing on an ext3 volume using ext2 code is not usually a problem. The journal will not be updated, so you may corrupt the disk if there is an unexpected shutdown or KDL. And Linux will run fsck to fix the journal on next boot. I’m not sure writing using ext3 code on an ext4 filesystem is a good idea, however.

Thanks for that explanation. I must try and remember that!

Is there a reason for detecting file type the Linux way instead of relying on file extensions? This way of detecting file type seems to create more problems that it solves. There is no situation where a file ending with .mp3 would be an executable unless someone hid a virus in the file.

In light of the explanation given by PulkoMandy, maybe Haiku should treat files on other mounted filesystems differently than it does native filesystems. It seems obvious that importing files from filesystems that do not have an executable attribute by automatically giving all files the executable attribute presents a real challenge. especially when the executable attribute appears to be the primary consideration for determining a file’s type. I did not have the problem working with these files in the Linux environment despite the executable flag being set.

Maybe the devs could revisit how file types are determined, especially on non native filesystems. What is to stop text files, spreadsheets, pdfs, images and all manner of other types of files from showing up as type “application” under Haiku? haven’t been able to think of an elegant way of dealing with this. Maybe someone with a better grasp of the inner workings of Haiku can think of something.

Since I now understand what the problem is, it is a minor quibble for me but, it could be really frustrating for folks new to Haiku, especially less technically savvy ones.

Tracker did warn you and fix the problem when you clicked on the file.
This is not a problem of filetype, which was detected properly.
It’s just that the algorithm is:

  • Is the file marked as executable? If so, try to execute it.
  • Otherwise, or if executing fails, look at the filetype and find the preferred app.
1 Like