1 On Windows 7, and Mp3tag V2.54 portable install on a read-only drive, launch Mp3tag
2 Exit
Expected: exit
Observed: "Access Denied" http://img23.imageshack.us/img23/4792/beta...dowedbetare.png - click OK exits.
It looks like this is due to Mp3tag attempting to write Mp3tagError.log, despite that there has been no error (except the one this causes).
Are you sure that it's the Mp3tagError.log ?? As in my case, this file gets created upon starting Mp3tag.
My guess it has something to do with the mp3tag.cfg ?
Let's wait for Florian's response on this.
Edit: */ Spelling
How did you find an option to install mp3tag as a portable version? I'd like to have a copy on a USB flash drive, but I see no option in setup (at least for the latest version v254) while installing it.
I stumbled upon the instructions here /t/964/1
Florian, I suggest it would be good to put these instructions in the Help.
Great... I ran a file comparison between the files in \Program Files\Mp3tag and \appdata\mp3tag and found several more than what was listed in that post. That's probably because it was originally installed in 2008, and has been updated at least once or twice.
All files matched on a binary comparison except \export\html_mp3tag.mte and \export\html_standard.mte which I guess were created by Mp3tag when I exported playlists to HTML files. The ones from \appdata were from 2008, and the ones from \Program Files from 2012.
I went ahead and synced all files in \appdata\mp3tag over to a copy of \Program Files\Mp3tag that I copied to a flash drive that weren't there originally. And it seems to be working fine. Haven't yet tested it, but I'll get back if I have any problems.
Thanks for that chrisjj.
TS
It's caused by trying to write mp3tag.cfg (which must be writeable even when using Mp3tag in portable mode).
Thanks. I hope you'll lift that limitation. Especially when there are no changes to write anyway.
What limitiation? If you arrange your file system in such a way that more or less anybody can use the data (and programs) in these folders then it is up to you to grant access to these folders.
A "portable" installation does not mean anything more than that all the required files reside in one basic folder instead of being spread over the file system.
If you then transport the data to various environments you would have to arrange the environment in such a way that the program fits.
And if there were nothing to write then you wouldn't get the error message, I would assume.
"mp3tag.cfg ... must be writeable even when using Mp3tag in portable mode"
I have arranged the file system such that appropriate access is given. And that appropriate access does not include write access. The folders are read-only for good reason - this is a production environment, and I do not want a production user changing any file in the programs folder, including any Mp3tag configuration file. I am not going to forego that protection just so that Mp3tag can write a config file that it doesn't need to write anyway.
If you read the report at the top of this thread, or tried it yourself, you find you've assumed wrong.
This still looks to me as though either the environment setup or the tool that you have chosen for your approach is not the optimum choice.
You know by now that a writeable cfg-file is a requirement and you still consider this to be a "limitation".
If the program requirements do not match with your "production environment" concept then I would say that the "production environment" concept has certain limitations.
As there has been no modification to MP3tag in the handling of the cfg-file I wonder how you deal with that.
Has your "production environment" gone out of production? Or have you thought of an alternative way?
If the latter is the case then there would be no point that others do the work for you, would there?
If you cannot "produce" - and this state will stay the status quo for some time - and you can live with it then the problem does seem to be a serious one.
That is why I do not really understand your persistance.
If you can suggest any way to prevent config changes other than the read-only solution I am employing, do say.
Likewise I do not understand yours. Esp. since you seem not even bothered to make the test yourself.
Why should I bother to make a particular test (which you do not know if I have or not) if it is pointless: the developer says,
then this is it.
I can live with that easily, be it in a portable installation or not.
And even if I test I find out: yes, the cfg file has to be writeable. And now?
I think that you somehow try to install some kind of separate user administration, only valid for MP3tag: some are just users with limited access to certain functions and others are the administrators.
MP3tag does not claim anywhere that it supports such an approach. So where is the limitation?
I still wonder what the purpose of the blocked cfg file should be? That you modify the files being read? The language?
I think that the plain editing functions in MP3tag can cause much more havock in a collection than any modified cfg-file. So how do you block modifications to the music files if they do not make sense?
Or do you use MP3tag as viewer? Then have a look at the subtitle: the universal tag editor. And editing means modification.
Coming back to an alternative: if you do not trust your plain users (which you should as you have to as long as you use Mp3tag) then create a cron job (or a repeated planned task) that copies an original portable MP3tag installation into the production environment. There may be a little time lag if someone has messed up things until the next cron job starts but that is a close as you can get.
And just a reminder of the current state of this thread: it has already been classified as "no bug" - it all works according to design. The limitation that you want to get removed, and I still think this is the case, lies in your approach but not in the Mp3tag features and functions.
Ah, just one thing: yes, one could claim that if one does not modify anything then why write a cfg file? To be honest: I do not know why MP3tag attempts to write but I bet the developer has a profound reason as he designed it that way. Without more knowledge about the internals we have to take his word for it that it is necessary. And that's it, no limitation.