Steve Fabian wrote
first, it's a bug ( damn ). the GUID is being extracted when it shouldn't.
secondly, yes, you are correct, the whole concept of injecting the GUID was to make it extremely difficult for unauthorized people to download files through any means other then the controlled method of doing so through the module.
third, the whole GUID concept is a hold-over from the early 'gooddogs' days before the module became part of the core. in the new version (3.01.14) currently in the tracker, I have added the ability to continue using the built-in GUID method, OR you can switch all your [FILE] and [IMAGE] tokens in your form.html files to [URLCONTROLFILE] and [URLCONTROLIMAGE] which will use the core upload and download methods and not inject the GUID.
so, it appears that the only way to solve your current issue is to upgrade to 3.01.14 and switch your tokens to use the new URL Control versions. Then the [FILEURL] token will work as expected.
Sorry you are having this problem.
Hey no need to appologuise! That's all part of software development, I'm glad I found something rather than just using it incorrectly :-P
I've just checked what version I have and it is 3.01.14, so all is good on that front. Although I'm a little confused now, will this help me resolve the URLs to files that I have already uploaded or does it mean that I have to upload again? This shouldn't be a problem really because I only have 4 MP3's on there at the moment, but my other repository which uses ZIPs would take days to reupload :( Basically all I was doing was embedding a small flash MP3 player into theTemplate.html for each MP3 file.
Anyways, I'll mod the MP3 templates so that it has the other tokens in for now, thanks a million for your time! :)