if you use the tag to name feature its possible for files to be renamed to outside
the target/working directory
for example say you have an typical move of %artist%\%album%$(num(2,%track%) - %title%
if the artist field is blank, the move goes to
eg the root of the current drive
someone mean might use this to do bad things (blank artist and album "windows"? won't corrupt but you can jam extra files in there)
I can think of real possibilities but not going to mention them on a public forum
The rename/move/etc features should be parsed to ensure files can't escape the directory.
and hey - thank you for a very cool program!
You can circumvent this by putting the directory part in square brackets. This way, the backslash only gets added to the result if the field is non-empty:
[%artist%\][%album%\]$(num(2,%track%) - %title%
But either way, it won't give the desired result and I don't see a viable solution to this -- except getting the tags right.
cool I didn't know about the  trick - Thanks
On the pathnames I don't know which development environment(s) you are using but you can use realpath() on posix compliant or _fullpath() on win32 to resolve the fully parsed path of a given string (it is a path/filename de-convolution, not checking existing files).
Then test that the parsed filename starts with the mp3tag current (destination) directory.
If you wanted, maybe let advanced users opt-out (disable safe filename checking).
Of course you only need to do the checks on the bulk tag->rename - if the user uses "move" or manual rename and trashes their system, thats their problem
(I use the move function to chuck files out of my working space all the time)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.