# \[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:** 1
**Showing post:** 7

<div class="post-metadata">

### Author: ![steh\_2511](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/e9bcb4/32.png) [@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")

</div>

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.

---

_[View the full topic](https://community.mp3tag.de/t/f-path-holds-extra/8524)._