Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bubla]

Hello,
when one tries to edit amule.conf when amule is running, all changes are lost because amule.conf gets rewritten periodically and those changes are lost (I suspect that it is because of statistics).
IMHO it is not a bad practice to edit config files of programs while they are running and then to just restart them to apply those changes...
I suggest adding a new file that would store these data or to put that to some other than a config file.

[Stu Redman]

Why don't you change the config options through the GUI as you are supposed to?
All user relevant options should be accessible through the GUI.

[Kry]

Edit configuration during program run is a dangerous little thing.

[bubla]

Thank for your replies,
now I see that I should have mentioned the background as well...

Why don't you change the config options through the GUI as you are supposed to?
All user relevant options should be accessible through the GUI.

If I run aMule on a server, the GUI doesn't work very well (at least amuleGUI).
When I browse files there, I can see that I browse local filesystem, not the remote one where the amule instance is actually running.
So I got quite suspicious regarding usage of GUI 

Edit configuration during program run is a dangerous little thing.

In most cases (daemons on Linux that I know), it is OK and even smart (you don't have to shut down the daemon during configuration adjustements).

Since we have nettops here that can serve as routers or low cost servers, I think that more people will consider running amule as a daemon, so it would not be bad to make it somehow easier for them, that's what I think and what is behind my suggestion...

[Kry]

I get your point, it's jsut that we would need some extra security involved on letting the user change the options like that. Plus, AFAIK we always keep a config file oject open so we would ahve to open/close it every time we change it to not interfere, and even then it could, and and and....

[lfroen]

It's funny: one day you have guy who complained that "you don't save config periodically, so when power dies, I've lost my changes". Another day come, and there's complain "why you save config periodically overwriting my changes".

[Kry]

Actually the first dude you mention was complaining about losing the ENTIRE config because the file got truncated by the filesystem driver.

[GonoszTopi]

Actually the first dude he mentions was complaining for losing his statistics (total UL/DL) when aMule crashes, because we only saved the config on exit.

[Stu Redman]

because we only saved the config on exit.

Do we? I think we save it periodically.

If I run aMule on a server, the GUI doesn't work very well (at least amuleGUI).
When I browse files there, I can see that I browse local filesystem, not the remote one where the amule instance is actually running.
So I got quite suspicious regarding usage of GUI 

While it's still far from perfect, setting the configuration should mostly work. File browsing is probably simply not implemented. You mean for setting up the shares?

Since we have nettops here that can serve as routers or low cost servers, I think that more people will consider running amule as a daemon, so it would not be bad to make it somehow easier for them, that's what I think and what is behind my suggestion...

Agreed, but I'd rather make it easier for them by improving the remote gui than by forcing them to edit the config and improve that.
Feedback on which config options don't work through the remote gui are always welcome. 

[phoenix]

If I am not missing something important, whe should only save configuration when the user changes something, what is the point on saving it periodically or even upon exit?

But I remember wx configuration had some strange behaviours and I don't remember the details right now.

[Stu Redman]

what is the point on saving it periodically or even upon exit?

The statistics (total upload, total download) are saved with the config.

[bubla]

If I run aMule on a server, the GUI doesn't work very well (at least amuleGUI).
When I browse files there, I can see that I browse local filesystem, not the remote one where the amule instance is actually running.
So I got quite suspicious regarding usage of GUI 

While it's still far from perfect, setting the configuration should mostly work. File browsing is probably simply not implemented. You mean for setting up the shares?

Yes, shares and cathegories.
Regarding the remote management, I don't really know what works and what does not. I once wanted to set up cathegories remotely and when I have discovered that the browsing stuff does not work, I gave up. Checking what setting works and what does not can actually be quite tedious. For example I have not found the "try to download first and last chunks first" option in the config file. Therefore I think that I can't reliably tell  whether it has been applied or not.

Since we have nettops here that can serve as routers or low cost servers, I think that more people will consider running amule as a daemon, so it would not be bad to make it somehow easier for them, that's what I think and what is behind my suggestion...

Agreed, but I'd rather make it easier for them by improving the remote gui than by forcing them to edit the config and improve that.

Well, AFAIK Linux users really love editing config files. Maybe others could, too. If you want to change aMule preferences remotely, you would probably prefer using ssh and then editing a (commented) config file. If you have an idea how is the thing you want to edit called, you just search for that option with an editor and you are done much faster than searching for in a menu and you know what is going on, you have control over things. Anyway, I don't want to force users to edit files if they don't like doing so, it's just about another approach.

And you don't have to have aMule installed to do this. Installing aMuleGUI just to be able to change amule settings is an overkill, isn't it? Well, at least for users who are familiar ssh Usually you get aMuleGUI only in a package bundled with aMule, moreover you have to satisfy dependencies, which can not be always possible.

The statistics (total upload, total download) are saved with the config.

Doesn't it sound strange anyway? Saving stats to config file?
You can have another file that is periodically updated, and it could contain internal statistics data, but maybe also a general transfers status - and you could peek on how are downloads going without having to use aMuleGUI at all. Maybe not usable for most users, but quite nice for people who like playing with things

Oh yes, and one thing more - since we have SSDs here, maybe the save interval of that file whatever file it is, should be adjustable. Since SSDs don't like rewrites, some users could prefer longer save periods.

[phoenix]

what is the point on saving it periodically or even upon exit?

The statistics (total upload, total download) are saved with the config.

Hum, I agree with bubla, we should have a different file for statistics.

[Stu Redman]

Well, AFAIK Linux users really love editing config files.

You'd wonder how many Linux users ask for help here and don't even know how to open a console. 

Installing aMuleGUI just to be able to change amule settings is an overkill, isn't it?

Well, you might also want to check the state of your downloads while you're at it, add new downloads, do searches, etc. You can do some of these tasks with amulecmd, but much less than with the remote gui.

editing a (commented) config file

You're thinking about your various Unix configs ? Don't forget amule.conf is written by the app too. I don't know app-written config files with comments. To get comments in there we would have to ditch the wx code we use and rewrite it all from scratch. No.

Since SSDs don't like rewrites, some users could prefer longer save periods.

aMule downloads data from the Internet, remember? The wear-level caused by this (and the logfile, don't forget that, and who-knows-what the OS does as well) outweighs the rewrite of a config file by magnitudes. And tests to damage a SSD (or even a cheap USB stick) by repeatedly rewriting data have been unsuccessful so far anyway.

Problem is that the wxDirSelector used for path selection has no plugin for providing remote paths (using the OS's dir picker dialog). So there is no easy way to fix this. It would require creating an all new selection dialog, with online data exchange about existing folders. (Which raises all kinds of security problems in the process...)
May we can just replace the dirpicker with a simple text field for the remote gui.

[bubla]

Well, you might also want to check the state of your downloads while you're at it, add new downloads, do searches, etc. You can do some of these tasks with amulecmd, but much less than with the remote gui.

I just meant that it would be nice to be able to do as much as possible using just SSH, since it is a common tool and sometimes you don't want / can't bother the owner of the computer by installing another software, even amulecmd. But I think that you can forget it, it would not benefit as much people as other things would.

editing a (commented) config file

You're thinking about your various Unix configs ? Don't forget amule.conf is written by the app too. I don't know app-written config files with comments. To get comments in there we would have to ditch the wx code we use and rewrite it all from scratch. No.

OK, so this is a problem. I don't mean comments, AFAIK it should be quite easy to list all options with their (default) values and then if something changes you just rewrite the value and you keep the rest, including comments that would be ignored othervise. Maybe wxFileConfig will support this in some way in the future...
The problem concerns what would have to be the result if you changed the config file and forgot to restart aMule and somebody would mess with prefs using GUI later.
Either:

• The person rewrites your settings (troublesome).
• Or that person could be warned that there are saved, but not applied settings out there that could get overwritten (nice, but it would complicate the aMule code).
• Or the config file could be periodically checked for changes (according to the date of modification) and those changes could get auto-applied (why not, but it sounds weird to me)

It IS strange, but do we want to break it?

Is there a reason to call it a breakage? I think that it could be done in a way that would preserve both backward and forward compatibility.

Since SSDs don't like rewrites, some users could prefer longer save periods.

aMule downloads data from the Internet, remember? The wear-level caused by this (and the logfile, don't forget that, and who-knows-what the OS does as well) outweighs the rewrite of a config file by magnitudes. And tests to damage a SSD (or even a cheap USB stick) by repeatedly rewriting data have been unsuccessful so far anyway.

Oh yes, I have forgotten, thank you for reminding me But seriously, I just have it running on my home server and I don't download stuff very often.
What can become a problem is rather fragmentation than destroying the SSD. The wear leveling algorithm that actually protects the SSD from physical damage moves saved data all over the place. This can increase fragmentation and lead to performance drops. Intel SSDs had such problems, and although they are reported to be more or less fixed, that applied to a normal system, personally I think that P2P apps would stress that much more from this POW.
See short article here: http://gizmodo.com/5157015/intel-ssds-may-suffer-from-irreparable-fragmentation-slowdowns
However you are right that this is deffinitelly not the biggest danger

Problem is that the wxDirSelector used for path selection has no plugin for providing remote paths (using the OS's dir picker dialog). So there is no easy way to fix this. It would require creating an all new selection dialog, with online data exchange about existing folders. (Which raises all kinds of security problems in the process...)
May we can just replace the dirpicker with a simple text field for the remote gui.

That would be nice. When I saw that broken picker, I have lost confidence in the remote GUI  

EDIT 8.8.09: Reformulated the clause concerning config file change and subsequent preferences change resolution