Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: New filesystem redirector service for relative paths in portable install (Read 1921 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New filesystem redirector service for relative paths in portable install

For most other readers, this is about an internal preview that is not public yet so please ignore.

I have my music and portable install on the same drive like this:

E:\Music
E:\Applications\foobar2000

I nuked my existing metadb.sqlite because I wanted to see the full effect of this as per the changelog and started again.

Library paths are now relative which is instantly problematic and will break many of my and I'm sure other people's components.

But worse than that, it breaks so much core functionality too.

Right click an album list entry>open containing folder. Nope...

Quote
Could not open folder: The parameter is incorrect.   (0x80070057)

After adding library items to a playlist they are relative like the library items but restarting fb2k makes the playlist paths absolute. Right clicking>open containing folder now works.

But the cached metadata from the library items is now gone...



Using the context menu to reload info works but as expected, the items are now duplicated in metadb.sqlite so I have 8 entries for the library items and 8 entries for the playlist items.



I didn't think much of it after the initial release on the 1st and thought it would be realised/fixed soon enough but there have been 3 more releases since with no mention of this so I'm a little bit concerned now.  ;D

Re: New filesystem redirector service for relative paths in portable install

Reply #1 –
Thanks, bug report noted, will fix for next build.
I can't yet figure out how you triggered this, all of this (including "open containing folder" which calls proper API to retrieve native path) is supposed to work.
Microsoft Windows: We can't script here, this is bat country.

Re: New filesystem redirector service for relative paths in portable install

Reply #2 –
Should be good now, please remove & re-add offending folders.

I know the idea of filesystem redirector sounds somewhat crazy, but it's not new, I had the same problem with Mac OS volumes that may change physical paths after remounting.
There's not much actual new code here, bugs are broken assumptions in old code.
Microsoft Windows: We can't script here, this is bat country.

Re: New filesystem redirector service for relative paths in portable install

Reply #3 –
That's better now. Thanks.

Is it expected that metadb_handle::get_path() will always start with file-relative:// now? This is breaking some of my components - fairly trivial for me to fix but it won't be great for people using other components which are no longer maintained.

Re: New filesystem redirector service for relative paths in portable install

Reply #4 –
Please use filesystem get_native_path() family of functions to obtain system-native path from any file path that has been handed to you, regardless of apparent path format.
As for unmaintained components, please name some examples for me to look at, maybe I can think of some workaround.
Microsoft Windows: We can't script here, this is bat country.

Re: New filesystem redirector service for relative paths in portable install

Reply #5 –
I don't have any examples so forget about that.

I did update my components earlier to use g_get_display_path because I was already familiar with it and it worked well enough but if g_get_native_path is your recommendation, I'll switch to it.

Re: New filesystem redirector service for relative paths in portable install

Reply #6 –
Found a bug with the context menu>Tagging>Attach Pictures>ANY TYPE.



Obviously the dialog opens but now you have to manually browse to the folder every time which is not pleasant.

Funnily enough, I have the exact same bug in one of my components that tries to do the same thing. My code looked like this and obviously supplying the native path to pfc::string_directory fixes it.

Code: [Select]
const auto folder = pfc::string_directory(handles[0]->get_path());

pfc::string8 image_path;

if (uGetOpenFileName(core_api::get_main_window(), "Picture files|*.jpg;*.jpeg;*.png;*.bmp;*.gif;*.tiff;*.webp", 0, nullptr, "Browse for image", folder, image_path, FALSE))
{

}

Re: New filesystem redirector service for relative paths in portable install

Reply #7 –
Nice find about album art ops, it's for no reason doing all sorts of deprecated stuff. Fixing.
Microsoft Windows: We can't script here, this is bat country.

Re: New filesystem redirector service for relative paths in portable install

Reply #8 –
More bugs:

can't drag/drop to Explorer
can't right click playlist items>Copy>Paste in Explorer.

Re: New filesystem redirector service for relative paths in portable install

Reply #9 –
I see the above issues are fixed now. Thanks.

Re: New filesystem redirector service for relative paths in portable install

Reply #10 –
Not strictly on the topic of relative paths but the fileDialog updates in today's preview have a scaling issue.

125% desktop scaling, windows 11 24H2. Text is not as sharp as it should be.



on previous previews/2.24.3, it's nice and crisp

Re: New filesystem redirector service for relative paths in portable install

Reply #11 –
Quote from: marc2k3 on
That's better now. Thanks.

Is it expected that metadb_handle::get_path() will always start with file-relative:// now? This is breaking some of my components - fairly trivial for me to fix but it won't be great for people using other components which are no longer maintained.
Does this affect JS components?

In particular SMP/JSP/JSplitter handle items expose a RawPath property which currently outputs "file://..."
https://theqwertiest.github.io/foo_spider_monkey_panel/assets/generated_files/docs/html/FbMetadbHandle.html#RawPath

And Path property without that "D:\SomeSong.flac"
https://theqwertiest.github.io/foo_spider_monkey_panel/assets/generated_files/docs/html/FbMetadbHandle.html#Path

Something which is used in pretty popular scripts like Library-Tree. And for sure my Playlist manager script also relies on that.

Looking at the source code and per marc's comments , I would say the change would simply break all JS components, since all track path handling makes use of that method.
https://github.com/TheQwertiest/foo_spider_monkey_panel/blob/997ad85febd614d30949e85c8df2c126f58038ed/foo_spider_monkey_panel/js_backend/objects/fb2k/fb_metadb_handle.cpp#L223

EDIT: Furthermore, there are like dozen of components using the method... just a quick search

foo_musicbrainz
https://github.com/kbuffington/foo_musicbrainz/blob/4588dcd8b836dd96a957d43d5986c88c8f3a1a04/src/dialog_tagger.h#L389
foo_openlyrics
https://github.com/jacquesh/foo_openlyrics/blob/45546bdb5d567b04ed10e99b723147e128efbd8a/src/config/ui_preferences_src_localfiles.cpp#L132
foo_midi
https://github.com/stuerp/foo_midi/blob/53214f832253b345cda5740e54d84922d943d7d9/MIDI/MIDISysExFilter.cpp#L36
foo_uie_webview
https://github.com/stuerp/foo_uie_webview/blob/e04a638e6536964fda6bd2a5b1fcfc965c8bc189/HostObjectImplFiles.cpp#L92

And those are only the open sourced ones I checked in 5 min. If marc's comments are right, this change is breaking a lot of components which were supposed to work fine on v2.

Re: New filesystem redirector service for relative paths in portable install

Reply #12 –
Yes, scripting components are affected. So any JS doing RawPath.startsWith("file://") will need updating.

Searching other component sources for ->get_path() isn't particularly constructive unless you know what you're looking for. For example, foo_musicbrainz is not affected by these changes. pfc::string_filename_ext extracts the filename only and still works with the new prefix.

In my own components, I did have to update Playlist Fix which was doing file:// + file existence checks to find dead playlist items. And I had to update my path hashing function in Cover Utils so old database records were not orphaned.

Re: New filesystem redirector service for relative paths in portable install

Reply #13 –
This feature is still in experimental phase and may not end being enabled by default, if it causes too much glitching.
It would be good to iron these issues out to pave the way for other future features relying on non-file:// paths in media library, like, SMB/FTP/WebDAV, or other redirection services (resolve USB devices by volume ID maybe?).
Microsoft Windows: We can't script here, this is bat country.

Re: New filesystem redirector service for relative paths in portable install

Reply #14 –
I have an obscure preview bug to report.

This is not relative path related as such but it does involve portable mode/file operations and the destination drive being the same drive as the portable install lives on.

Also, this is not something anyone should expect to encounter because the destination is the root of the drive. If I specify a folder or choose the root of another drive, there is no problem.

As you can see from the preview, fb2k thinks it should be creating a folder (..) inside the portable install folder (Z:\foobar2000) but the actual tracks to copy and their destination are correctly listed.



If I proceed with this, I get this error.



Re: New filesystem redirector service for relative paths in portable install

Reply #15 –
Thanks for the recent fixes in the issues I mentioned.

But today I noticed the fooHelper bundled with 32bit fb2k does not contain the DPI manifest fix. It's still blurry.
 

Re: New filesystem redirector service for relative paths in portable install

Reply #16 –
Thanks, fixed.
Microsoft Windows: We can't script here, this is bat country.