aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: [1] 2 3

Author Topic: Amule.conf corruption risk  (Read 21071 times)

stoatwblr

  • Sr. Member
  • ****
  • Karma: 12
  • Offline Offline
  • Posts: 318
Amule.conf corruption risk
« on: June 06, 2009, 08:34:11 PM »


I'm finding that if there is a system crash, there is a high probablity that amule.conf will be truncated to 0 bytes. I'm assuming that's because the conf file is rewritten in place periodically as the  DL/UL stats are updated.

NOTE: This is always a risk if a file is open and being written at the time there's a crash, even on a journalled filesystem.

The safest way of rewriting any file is to do it beside the existing one and then to rename it into place.

Logged

stoatwblr

  • Sr. Member
  • ****
  • Karma: 12
  • Offline Offline
  • Posts: 318
Re: Amule.conf corruption risk
« Reply #1 on: June 20, 2009, 01:23:51 PM »

*Bump*

Guys, has this been noted and will the code be tweaked?

Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Amule.conf corruption risk
« Reply #2 on: June 20, 2009, 01:32:22 PM »

Yes and not really any time soon. It's not as simple as you see it.
Logged

stoatwblr

  • Sr. Member
  • ****
  • Karma: 12
  • Offline Offline
  • Posts: 318
Re: Amule.conf corruption risk
« Reply #3 on: June 20, 2009, 04:08:42 PM »


It's a serious issue. The current way of updating is a race condition which has repeatedly  resulted in corrupted/truncated copies of amule.conf

With  journal updating=ordered(default for Ext3/4, ntfs and BSD journallng), there's a better than 50% chance the file will get trashed if a machine is front-panel reset/power goes off while amule(d) is running.

Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Amule.conf corruption risk
« Reply #4 on: June 20, 2009, 04:20:45 PM »

Which is not aMule's fault, I'm sure you see.

Incidentally, amule.conf also gets corrupted if you take your harddrive out and throw it down from the 20th floor of a building, if you submerge your computer in acid, or if you nuke the country your computer is in. There is a limit for paranoid security settings, and hardware failures (unexpected power off is a hardware failure) are in the thin red line.

The filesystem should ensure the consistency of the data, and recover from failures gracefully. A lazy approach like the one this filesystems are taking causes data loss, of course.
Logged

lfroen

  • Guest
Re: Amule.conf corruption risk
« Reply #5 on: June 20, 2009, 04:48:47 PM »

It's a serious issue. The current way of updating is a race condition which has repeatedly  resulted in corrupted/truncated copies of amule.conf
What is "it"? Where is this "race condition"?

With  journal updating=ordered(default for Ext3/4, ntfs and BSD journallng), there's a better than 50% chance the file will get trashed if a machine is front-panel reset/power goes off while amule(d) is running.
So, hmm - don't press that button, please? Corrupted amule.conf may be least of your problem if you do.
Logged

stoatwblr

  • Sr. Member
  • ****
  • Karma: 12
  • Offline Offline
  • Posts: 318
Re: Amule.conf corruption risk
« Reply #6 on: June 21, 2009, 12:01:21 PM »

It's a serious issue. The current way of updating is a race condition which has repeatedly  resulted in corrupted/truncated copies of amule.conf
What is "it"? Where is this "race condition"?

The race condition is caused by overwriting the configuration file in place - when you do this the file is truncated to zero bytes, then filled.

Most of the time you can get away with doing things like this, but it leaves a window of vulnerability and it's bad practice. The safe method is to write a new file and then rename it over the old file. (Yes the inode changes, but you're not locking the file open permanently, are you?)


As an example of why rewriting in place is bad practice: About a decade ago I spent more than a week tracking down why an ISP  sendmail installation was apparently randomly rejecting email to valid users. It turned out that a homegrown alias update script was taking about 1 second to complete - during that time the alias.db and virtusers.db files were truncated to 0 bytes - During the time between the files being 0 bytes and being valid dbm tables, all inbound mail was being bounced.

Multiply that by the server in question being an ISP machine handling 40-100 pieces of email per seconds and you start seeing why race conditions can be very bad news.

Logged

stoatwblr

  • Sr. Member
  • ****
  • Karma: 12
  • Offline Offline
  • Posts: 318
Re: Amule.conf corruption risk
« Reply #7 on: June 21, 2009, 12:06:35 PM »

Which is not aMule's fault, I'm sure you see.

The exact words used by several professional programmers when I described how amule.conf was being rewritten were:

"####ing kids in bedrooms!"

Which might give you an idea of  how they regard the practice.

As for throwing the drive down the stairs - no need when the neighbourhood power supply keeps dropping out unexpectedly thanks to copper thieves attacking distribution stations.
Logged

fabtar

  • Approved Newbie
  • *
  • Karma: 1
  • Offline Offline
  • Posts: 24
Re: Amule.conf corruption risk
« Reply #8 on: June 21, 2009, 12:18:51 PM »

A bunch of emule mods have an automatic backup feature for config files (mantains a copy) . This may be useful in case of  disk failure or  power failure.
This is not a very important feature but make sense in some circumstances. Naturally the motivation behind this feature is bit different than "..in case I push the power button"   ;)
 edit :
remove
 "..in case I push the power button"  , and add "copper thieves" which are a quite different topic.(we have wrote messages at same time)

P.s: Have you considered buying an UPS or  a Generator?

P.s:About " The safe method is to write a new file and then rename it over the old file" ; i'm a bit noob but this makes sense.
« Last Edit: June 21, 2009, 12:26:56 PM by fabtar »
Logged
Mldonker looking around

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Amule.conf corruption risk
« Reply #9 on: June 21, 2009, 02:24:36 PM »

Which is not aMule's fault, I'm sure you see.

The exact words used by several professional programmers when I described how amule.conf was being rewritten were:

"####ing kids in bedrooms!"

Which might give you an idea of  how they regard the practice.

That's cool. As you have proxied their opinion to me, rely my opinion to them: "Go fuck yourself, you ignorant piece of shit that talks about things he doesn't know shit about".

You can apply it to you too if that's your opinion. I already told you that it's more complicated than it seems. For example, we're not fucking rewriting the file, we're using wxWidget's wxFileConfig facility to access, read and modify the configuration file. If it is your opinion that the file should be flush()ed in any special way, take it with them. See, now it's showing that you're blaming us and flaming us without having any fucking clue what's going on, and looking like a complete cunt.

Now, if you think that for every write access to the config file we're going to a) create a new wxFileConfig object with a new path b) Copy all configuration data to the new file c) Modify the contents of the new file d) Overwrite the old file with the new file, you're as they say, S.O.L.

Hint: Filesystem integrity is at kernel/driver abstraction level, not application level. Applications shouldn't have to deal with that shit, because they're on a different abstraction level. Seriously, if you're having the problem that your filesystem is left in a fucked up state because of a power failure on a regular basis, put your own driver/script measures to protect sensitive content in place.

As for throwing the drive down the stairs - no need when the neighbourhood power supply keeps dropping out unexpectedly thanks to copper thieves attacking distribution stations.

So don't worry, we will modify our code, make it overcomplicated and redundant and full of unnecessary overhead and everything so the copper thieves can continue acting without you losing your aMule configuration!

CALL THE FUCKING POLICE, MAN. YOU HAVE ISSUES WITH TRYING TO SOLVE SYMPTOMS, NOT PROBLEMS
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Amule.conf corruption risk
« Reply #10 on: June 21, 2009, 02:46:43 PM »

Oh I forgot to say the magic words, "no offense meant"
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Amule.conf corruption risk
« Reply #11 on: June 21, 2009, 02:47:21 PM »

Except to those so-called "professional programmers", those can go fuck themselves.
Logged

stoatwblr

  • Sr. Member
  • ****
  • Karma: 12
  • Offline Offline
  • Posts: 318
Re: Amule.conf corruption risk
« Reply #12 on: June 21, 2009, 03:10:06 PM »

Except to those so-called "professional programmers", those can go fuck themselves.

Given that they write code for spacecraft control systems and banking systems I think I know whose opinion is more valid.

Here's a free clue: Google. Bugtraq, "race condition"

Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: Amule.conf corruption risk
« Reply #13 on: June 21, 2009, 03:16:04 PM »

Here's a free clue: I know that shit. It doesn't apply to a userspace non-critical program.

Their opinion is worth shit because they don't know what they're having an opinion about. Would I go out of my way to do this in a sensitive system? Hell yes. As a matter of fact I do in my job. Do I think it makes any sense to change it in aMule? Hell no. I already explained to you why.

This is not about whose opinion is more valid. This is about them insulting us without knowing the facts, which is mainly your fault anyway. They can still go fuck themselves, tho.
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: Amule.conf corruption risk
« Reply #14 on: June 21, 2009, 03:22:40 PM »

Given that they write code for spacecraft control systems and banking systems I think I know whose opinion is more valid.
Now you are starting to piss me off too. Why don't you use a spacecraft control system or banking system to download your stuff?
And read before posting:
For example, we're not fucking rewriting the file, we're using wxWidget's wxFileConfig facility to access, read and modify the configuration file. If it is your opinion that the file should be flush()ed in any special way, take it with them.
Go to the right place with your complaint (wx tracker) before Kry feels the need to write in 100pt letters.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon
Pages: [1] 2 3