Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

Codecov Report

Merging #37834 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master   #37834   +/-   ##
=========================================
  Coverage     64.75%   64.75%           
  Complexity    19392    19392           
=========================================
  Files          1284     1284           
  Lines         75755    75756    +1     
  Branches       1333     1333           
=========================================
+ Hits          49057    49058    +1     
  Misses        26306    26306           
  Partials        392      392           

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b9e4f61...db08a09. Read the comment docs.

Since setupFS function does not allows second initialization

That's a safety net that we have but we shouldn't use or abuse. If you call the setupFS function twice, you have a problem to solve. In fact, I think we should have a debug log (or even I warning) to detect this problem easily.

According to my investigation, the problem isn't that the setupFS isn't called but the app calls the FS too early. The FS isn't initialized yet when the 3rd-party app is being loaded.
I think we should check the app loading order. It makes more sense to me that core calls the setupFS after all the filesystem apps are loaded. In this case, the music app should be loaded after the filesystem apps (I don't see a reason why the music app should be tagged as filesystem app).
Obviously, the same problem could happen with apps that must be loaded before the FS (session, authentication... apps), but that's kind of expected.

@jvillafanez

I don't see a reason why the music app should be tagged as filesystem app

Do you mean this definition in the info.xml:

<types>
	<filesystem/>
</types>

?

If yes, then that's actually pretty important for any app which listens the filesystem hooks, and depends on them for correct functionality. If this tag is not given, the application is allowed to be "Enable only for specific groups" by the admin. When this is done, the application cannot react to the file system hooks from all users, and the music database may end up to inconsistent state, containing references to files which do not exist.

@karakayasemi @paulijar @jvillafanez @micbar Applying the patch works, I tested manually.

Which are the next steps?

I'm not fully happy with the solution, but I don't want to block this fix. If everyone agrees, I'm fine with merging the PR.

@karakayasemi please rebase

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information