Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beats: Fix file permissions on FAT so it can see custom MP3s. #18485

Merged
merged 1 commit into from
Dec 8, 2023

Conversation

hrydgard
Copy link
Owner

@hrydgard hrydgard commented Dec 7, 2023

On FAT file systems, files look like they have executable permission. For some reason Beats checks for this.

Unfortunately, this doesn't really make custom music playable - while they now display, they seem to start stuttering after a short while. Or it's just my files...

Also, should write a pspautotest...

On FAT file systems, files look like they have executable permission.
For some reason Beats checks for this.

Unfortunately, this doesn't really make custom music playable - while
they now display, they seem to start stuttering after a short while. Or
it's just my files...
@hrydgard hrydgard added the I/O Affected by I/O timing settings, or other kind of I/O issue. label Dec 7, 2023
@hrydgard hrydgard added this to the v1.17.0 milestone Dec 7, 2023
@anr2me
Copy link
Collaborator

anr2me commented Dec 7, 2023

Probably because FAT doesn't have executable attribute, thus always executable (with the exception of directory type)

@hrydgard hrydgard merged commit c6db963 into master Dec 8, 2023
18 checks passed
@hrydgard hrydgard deleted the beats-mp3-dir-fix branch December 8, 2023 23:01
Comment on lines +2509 to +2510
// All files look like they're executable on FAT. This is required for Beats, see issue #14812
entry->d_stat.st_mode |= 0111;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. I thought we had a test for this against memstick, but maybe it was actually from host0. However, almost always directories should have the executable bit (some filesystem libs will interpret that correctly as "can traverse" and might restrict to avoid syscall errors.)

Does it fix Beats if it's only directories?

-[Unknown]

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, i guess it's similar to the contents of iOS' IPA(which is a ZIP) where all the folders have executable attribute even when the files in it aren't executable.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Unix/BSD/Linux/etc. rule is that the 1 bits mean execute for files, and mean "search" or "traverse" for directories - in other words, ability to descend into and access files within. iOS is based on Darwin which is based on BSD, so it inherits the same meaning for those file mode bits.

-[Unknown]

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I tested this, and I confirmed it now - we need the executable flag on the files too, not just the directories.

In fact, we can skip setting execute on the directories and it still works.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, strange.

-[Unknown]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I/O Affected by I/O timing settings, or other kind of I/O issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants