[DaveBlake]

My view on this is that having reserved characters in file/folder names is perfectly acceptable and expected (used Windows too long I guess). At most maybe the wiki needs an update.

I filed the issue on GitHub back in July. I think I did a pretty good job of figuring out why this changed for Kodi 18 (note: this never happened in previous version)....

To summarize: this isn't about special characters and uniformity across platforms. It's about improperly identifying libnfs files as URIs and applying options/parameter stripping logic to those paths. The fix should be as simple as updating IsURL to return false for nfs:// and smb://.

Clearly you are more concerned about this, and if you think there is behaviour to be restored and have a fix to do that then raise a PR. But be warned, IsURL is used in many places, messing with path processing is something very fundamental and must be done with care.
 
I am based on Windows, so unable to add reserved chars to file/folder names to even investigate it

[Uatschitchun]

If I may ask, why would a reading application needs to make a consideration about what characters are allowed?
It really only matters for when an application wants to write. Only then it has to take care of what the underlying file system allows!?

If the application is presented a path, that path is valid as otherwise the path wouldn't be like it is.
If an application is presented a path without a 'special character', it could be because there simply is none of these characters or because the underlying layer does not allow those characters. But if there are those characters, it must be, because the underlying layer allows these characters.

There's even no checking done by kodi against permissions for the underlying file system. If I would like to create a folder or do an export, kodi will not check if it's allowed to write into the desired folder, but it would throw an error.

So please could someone explain, why there's a need to do checks or truncations?

smb & nfs are standardized protocols. For NFS see: https://tools.ietf.org/html/rfc2224

1. URL Syntax

   An NFS URL is based on the Common Internet Scheme Syntax described in
   section 3.1 of RFC 1738.  It has the general form:

        nfs://<host>:<port><url-path>

   The ":<port>" part is optional.  If omitted then port 2049 is
   assumed.  The <url-path> is also optional.

   The <url-path> is a hierarchical directory path of the form
   /<directory>/<directory>/<directory>/.../<name>. The <url-path> must
   consist only of characters within the US-ASCII character set.  Within
   a <directory> or <name> component the character "/" is reserved and
   must be encoded as described in Section 2.2 of RFC 1738.  If <url-
   path> is omitted or consists solely of "/", it must default to the
   path ".".

[Uatschitchun]

I am based on Windows, so unable to add reserved chars to file/folder names to even investigate it

Take some old USB-Stick or spare drive and try:
https://www.disk-partition.com/articles/...-7201.html

Together with ExtFS: https://www.paragon-software.com/busines...r-windows/

You're ready to go

[DaveBlake]

I already have plenty of work that I consider a higher priority thanks. I have to say I can't understand why you are so exasperated by this @Uatschitchun , rename the file and move on.

As for explanations.... You are thinking far too simplistically. Kodi can be presented a "path" in many ways (GUI, JSON, scripts) and no they are not all valid phyiscal file locations just because they have been presented. A path could be a URL (with or without protocols), networked, local, for a folder, file or a stream, or even a virtual path that encodes a library location, smart playlist, custom node,  or screen. The term "path" in Kodi and how it is processed is very diverse.

[Uatschitchun]

I already have plenty of work that I consider a higher priority thanks.

Was a joke ;)

As for explanations.... You are thinking far too simplistically.

KISS

Exasperated?

Spending weeks for to shape your data to the needs of a little diva called kodi just to stumble upon a question mark feels unfair ;)
Throughout the forum there's the "tag with MBID" mantra. So I tag with MBID and I move and order the my files with Picard => so they get some special characters within their filename.

Again, bringing data into a useable shape for kodi is a lifetime job ;)

Ok, nice. Files are tagged and sorted, artwork is updated, time to set up the database and only with using libnfs as source instead of a share mounted to my filesystem, hundreds of files aren't working anymore that worked before. Because of what? Because I tagged and named them with Picard? Because I do not use Windows compatible filenames with a Unix protocoll? WTF?!

This limitation only comes to live when using libnfs!!! I bet your're not sharing Web-URLs, streams, JSON calls or whatever with NFS!

And I bet that if it's possible to properly use, play and open a path like:

Code:

/media/music/?unsorted?/three???/file1:of2-(ß).mp3

it should certainly be possible to properly open, play and use a path like:

Code:

nfs://192.168.1.1/media/music/?unsorted?/three???/file1:of2-(ß).mp3

???

[DaveBlake]

Tag music files with Picard, no one ever said anything about naming them with it.
You really have hundreds of files with "?" in the name? How unexpected, and from my view point what a strange thing to do. As I said somewhere I still think twice before using spaces in names, avoiding reserved chars is natural to me.

Honestly no one has been deliberately plotting to make your life harder, it sounds like you are feeling that way. Kodi does not only play music files, it plays streams from sites with account details and passwords, it plays library entries, smart playlists etc. A "path" string is passed as the parameter in all these cases and has to be decoded. Some of those "path" strings have "|" or "?" as option delimiters, it is therefore no surprize to me that they would cause issues in file names. Meanwhile there is no "should" when it comes to Kodi, it does not have a requirement specification. It does what it does. I guess that could make it a diva.

[HeresJohnny]

I guess only we Germans would make a problem of how exactly we want to name a file doesn't work and not think about workarounds. Naming it "Die drei Fragezeichen" or even "Die Drei" would be equally descriptive and not tie up our main music coder.

[DaveBlake]

No worries I am not tied up by this particular thread.  I decided long ago to find the diversity of user viewpoint (and ways of using Kodi) as a voyage of discovery. I question those user view points and user's ways of doing things, because I like to understand. Frequently being on the recieving end of opinions I also feel free to express and explain my own view. Sometimes insightful and productive things come out of the exchange, so it is never wasted discussion.

[Uatschitchun]

Pls do me a favor and try to abstract with me on this:
What I'm trying to say is that paths beginning with "nfs://" need no handling of special characters like "?" or "|" as those characters are perfectly in line with the protocol's specifications.

I'm not talking about my specific use case here! I've solved it already (although being german I'm able to find workarounds!) with using system mounted nfs shares instead of using libnfs, as it's far easier to mount 2 folders on system level and still being able to tag and move/rename with picard instead of taking care of special characters when doing so, with always the need to remember to not use those characters or remove them.

So, with distinguishing "nfs://" as a special kind of URL without the need to cut off after a "?", kodi's libnfs implementation would go conform with the nfs protocol.
There are use cases where it's not easily possible to mount nfs shares on system level (Android for instance or Windows). Solving this would allow libnfs to be in line with system mounted nfs shares.
This, in the end, will certainly minimize hassle, questions and misunderstandings.

Libnfs is a glorious implementation as it allows using network shares (like smb) from all devices, whether they would allow mounting shares on system level or not without the need to take care of filenames and without the need of (re-)arranging media!

---

And yes, there are a lot "?":

Code:

/music$ find ./ -name "*\?*.mp3" | wc -l
820

Code:

/audioplays$ find ./ -name "*\?*.mp3" | wc -l
2264