[F] %path% holds extra \

On a file dragged into mp3tag, %path% returns the expected value e.g.

S:!DJ DAP\3 ZEN\Dance\GW w-a.wma

but on the same file loaded by

start "Mp3tag Dance" "%PROGRAMFILES%\Mp3tag\Mp3tag.exe" /fp:"%~dp0\3 ZEN"

%path% includes an extra \

S:!DJ DAP\\3 ZEN\Dance\GW w-a.wma

Workaround: at every reference, have script to remove the extra \ :frowning:

Is there an easier workaround? Please let there be a secret %unmessedpath% :slight_smile:

Hi,

looks like you are using a batch for calling mp3tag, which resides in your
S:!DJ DAP directory.

The issue depends on the variable-expansion of the shell (cmd.exe):
%~dp0 expands to S:!DJ DAP</b> with the trailing backslash

So, simply remove the backslash in front of 3 ZEN (or behind %~dp0 :slight_smile: )
and you are fine.

simply remove the backslash in front of 3 ZEN

/fp:"%~dp03 ZEN" works fine. Thanks for the great workaround!.

Hi crissjj,

please let me give some clarification:

simply remove the backslash in front of 3 ZEN

/fp:"%~dp03 ZEN" works fine. Thanks for the great workaround!.

This is not a workaround; it's a bugfix for your environment!
I think it's important to clarify that there was no issue with mp3tag.

Nevertheless I'm happy that I could help you.

Kind regards

Despite this "work around" (better named as "work to the point") the situation of having a non canonicalized folder/file path within the Mp3tag application should not happen (user errors should be handled as smart as possible).

To make a file path valid there are numerous system based functions avaliable, e. g. Microsoft Windows Shell lightweight utility functions, e. g.
PathCanonicalize Function
http://msdn.microsoft.com/en-us/library/bb773569(VS.85).aspx
PathSearchAndQualify Function
http://msdn.microsoft.com/en-us/library/bb773751(VS.85).aspx
... and surely thousands of similar validation tools built by programmers from all over the world.

DD.20090629.2026.CEST

1 Like

This is not a workaround; it's a bugfix for your environment!

I'd say it is both.

I think it's important to clarify that there was no issue with mp3tag.

Disagreed. I consider Mp3tag's failure to canonicalise the path to be a bug.

"bug" being "deficiency causing failure to meet reasonable user expectation". I accept your definition of "bug" may differ.

Florian, I do hope you'll address this.

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.

If a feature is undocumented, how can anyone know a use of it is faulty? :wink:

Sadly Mp3tag's documentation is somewhat dispersed. The HTML docs are known to be incomplete and are not held as a definition of program behaviour. If there had been complete docs, they would no doubt have defined acceptable usage and presumably excluded the usage I made. Hence I wouldn't have made the usage I guessed. Yes, it would be better if we didn't have to guess. But we do.

1 Like

I'll try to canonicalize the incoming paths with the next release. In the meantime I made the command line interface an official feature: Mp3tag Help - Command Line Interface.

Kind regards,
Florian

I'll try to canonicalize the incoming paths with the next release.

Thanks.

In the meantime I made the command line interface an official feature:
Mp3tag Help - Command Line Interface.

Excellent. May I suggest this page also cover the method for Add directory: Loading multiple folders on launch .

PS

Starts Mp3tag with the specfified audio file

s/specfified/specified/

Fixed :slight_smile:

Verified :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.