Oh, some action here.
I want to give some explanation on my hint.
I found the existence of the /fp: command line option throught the registered
shell extension (right-klick on a directory) and thought, it could be
usefull to differentiate the working dirctory - where default filesystem
opperations reside - from the scan path (/fp:) - which the program uses
as root to find audio files.
This all was an assumption about the behaviour of the program.
As I run into similar problems with /fp: like chrisjj do (see also this thread),
I unsportsmanlike reviewed the html documentation:
Nothing about /fp: or the role of a working directory or a scan path root is
documented!
So I have to conclude that the assumption about the behaviour of the program
as I stated before is faulty, it seems that it is quite different from the
authors program design, where the role of /fp: parameter is intended to
implement the shell extension functionality - Fabian, please correct me,
if i'm wrong.
In this context, the program always can be sure to get well-formed,
canonicalized string representations of an existing directory - the
operating system itself takes care of this.
In my opinion it has to be indisputable that:
The faulty usage of an undocumented "fictional feature" can not lead into a
bug report situation.
At the other hand - and I agree 100% with the contents of DetlevDs post here:
It's a good idea to prevent a user from smuggling funny strings into
%_path%, for instance something like "D:\\///\\mp3/////\tagged" is posible
and the usage of an relative path leads in confusion or program hang.
Now, I want to stop with laberrababer and
close with my respect to Fabians work:
The usability of mp3tag is great for me.