# \[F\] %path% holds extra \\
**URL:** https://community.mp3tag.de/t/f-path-holds-extra/8524
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [June 28, 2009, 11:02pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524 "2009-06-28T23:02:30Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [June 28, 2009, 11:02pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/1 "2009-06-28T23:02:30Z")
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 \ ☹
Is there an easier workaround? Please let there be a secret %unmessedpath% 🙂
---
### Author:  [@steh\_2511](https://community.mp3tag.de/u/steh_2511)
#### Post date: [June 29, 2009, 12:23pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/2 "2009-06-29T12:23:23Z")
Hi,
looks like you are using a batch for calling mp3tag, which resides in your
_S:!DJ DAP_ directory.
> [@chrisjj](#):
>
> ...
> start "Mp3tag Dance" "%PROGRAMFILES%\Mp3tag\Mp3tag.exe" /fp: **"%~dp0\3 ZEN"**
> ...
The issue depends on the variable-expansion of the shell (cmd.exe):
**%~dp0** expands to **S:!DJ DAP\ with the trailing backslash**
So, simply remove the backslash in front of _3 ZEN_ (or behind _%~dp0_🙂 )
and you are fine.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [June 29, 2009, 3:08pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/3 "2009-06-29T15:08:08Z")
> simply remove the backslash in front of _3 ZEN_
/fp:"%~dp03 ZEN" works fine. Thanks for the great workaround!.
---
### Author:  [@steh\_2511](https://community.mp3tag.de/u/steh_2511)
#### Post date: [June 29, 2009, 4:08pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/4 "2009-06-29T16:08:09Z")
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
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [June 29, 2009, 4:16pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/5 "2009-06-29T16:16:56Z")
> [@chrisjj](#):
>
> ... /fp:"%~dp03 ZEN" works fine. Thanks for the great workaround!.
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](http://msdn.microsoft.com/en-us/library/bb773569(VS.85).aspx)
PathSearchAndQualify Function
[http://msdn.microsoft.com/en-us/library/bb773751(VS.85).aspx](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
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [June 29, 2009, 4:42pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/6 "2009-06-29T16:42:43Z")
> 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.
---
### Author:  [@steh\_2511](https://community.mp3tag.de/u/steh_2511)
#### Post date: [June 30, 2009, 12:18pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/7 "2009-06-30T12:18:44Z")
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](https://community.mp3tag.de/t/8530/1)),
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.
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [June 30, 2009, 12:39pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/8 "2009-06-30T12:39:20Z")
> [@SteH](#):
>
> 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.**
If a feature is undocumented, how can anyone know a use of it is faulty? 😉
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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [July 4, 2009, 11:09am UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/9 "2009-07-04T11:09:23Z")
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](https://docs.mp3tag.de/command-line).
Kind regards,
Florian
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [July 6, 2009, 9:28pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/10 "2009-07-06T21:28:21Z")
> 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](https://docs.mp3tag.de/command-line).
Excellent. May I suggest this page also cover the method for Add directory: [Loading multiple folders on launch](https://community.mp3tag.de/t/7690/10) .
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [July 7, 2009, 1:25pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/11 "2009-07-07T13:25:27Z")
PS
> Starts Mp3tag with the specfified audio file
s/specfified/specified/
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [July 12, 2009, 5:26pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/12 "2009-07-12T17:26:44Z")
[Fixed](http://developer.mp3tag.de) 🙂
---
### Author:  [@chrisjj](https://community.mp3tag.de/u/chrisjj)
#### Post date: [July 14, 2009, 6:42pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/13 "2009-07-14T18:42:44Z")
Verified 🙂
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:01pm UTC](https://community.mp3tag.de/t/f-path-holds-extra/8524/14 "2018-12-28T14:01:27Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.