Print

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

[Leviathan]

Hi,

sorry for putting 3 bugs into one thread, but I didn't want to spam the board.
All these bugs are new to 2.1.0, they didn't appear in 2.0.3.

1. amule requires read-access to the incoming-directory. I don't see a reason for that. My incoming directory is chmoded 773, which I want to keep...
2. amulegui seems to go into an infinite loop if there is no daemon running on the host-machine specified.
3. I tried using ExecOnCompletion to move the finished file when it's ready. That caused amuled to crash every time on completion of a file (without message to the logfile). The file was correctly moved however.

[lionel77]

Originally posted by Leviathan
1. amule requires read-access to the incoming-directory. I don't see a reason for that. My incoming directory is chmoded 773, which I want to keep...

Correct me if I am wrong, but if aMule does not have read access to the incoming folder, every file is immediately unshared after completion. I don't think aMule should encourage this kind of behavior.

[Leviathan]

Originally posted by lionel77Correct me if I am wrong, but if aMule does not have read access to the incoming folder, every file is immediately unshared after completion. I don't think aMule should encourage this kind of behavior.

This is true. However, there are easier ways to prevent files from being shared. If I didn't want to share, amule couldn't force me, especially not considering it is open-source...
The reason my users don't have read-access to the incoming folder is the following:
I have a script running that uses inotify (notification on file-access) to monitor that directory. Whenever a new file is placed in "incoming", it's checked for viruses and then sorted into another directory structure. That directory is read-enabled for users and shared through amule.
The incoming directory is read-disabled so users can't access files that haven't been checked for viruses or disturb the script.
Now I can of course sort this out using groups to allow p2p to read that dir but not other users.
Still, I consider it faulty behaviour from a software if it requires more permissions than is neccessary for its operation.

[Kry]

Reading from the Incoming folder is a basic operation given that the incoming folder is always shared. I see no faulty behaviour.

The correct behaviour for what you want, is using group, not forcing the app to change its behaviour.

[Leviathan]

"It's not a bug, it's a feature" then...
Well, it's your program. If you consider this correct behaviour, I can hardly argue. (I'll still try though. )
Using a group is a workaround however, not a correct or clean solution, because it forces me to share the files in incoming although I know they will be moved a few seconds later.
It also forces me to share files I didn't have the chance to scan for viruses, which is what I want to prevent with the script I mentioned above.

But ok, that's one of the bugs on my list. Am I the only one experiencing the other 2?

[Xaignar]

You will share files as they are being downloaded in any case.

[Kry]

Bug 2 is not a bug. wxWidgets has a 10 minute timeout on sockets. Go figure.


I'll change it to a sane amonut at some point.

[Leviathan]

Originally posted by Xaignar
You will share files as they are being downloaded in any case.

Yes, but that can't be helped, unless people would only share files they already downloaded completely, which would produce a serious performance-hit.

But the enforcement of read-access to incoming is an artificial limitation and it's removal would have no negative consequences whatsoever.

Please don't misunderstand me. This is not a big problem or something to fight about, it just makes my life a bit harder and I don't see the reason.

@Kry: 10 minutes? seriously? that is indeed insane.

Thanks guys for your quick answers.

[Kry]

aMule automaticlly shard the files on incoming. Making sure we ahve read access is in no way an "artificial limitation"

[lionel77]

Originally posted by Leviathan
3. I tried using ExecOnCompletion to move the finished file when it's ready. That caused amuled to crash every time on completion of a file (without message to the logfile). The file was correctly moved however.

Just to make sure I understand, if amuled did not crash upon ExecOnCompletion, issue 1 would be a moot point for your setup, right? So maybe we should just try to prevent amuled from crashing in that situation...

[Xaignar]

If you could produce a backtrace for the ExecOnCompletion crash, I'll take a look at fixing that.

[Leviathan]

Exactly. ExecOnCompletion was what I tried when I realized my original setup wasn't working.
Maybe it will work if I use a "sleep" to delay the move-command? the gui seems to stop receiving data while the file is still being displayed as "completing", so maybe amuled expects the file in its old position after ExecOnCompletion has been called.

[Xaignar]

The command is executed after all other completion tasks have been performed, so that shouldn't be the case.

[Leviathan]

Shortly before the crash I get a lot of these errors:

Code: [Select]

addr2line: 'amuled': No such file
2006-01-05 21:41:13: Debug: Empty addr2line output?
But I guess that is unrelated...

Then this:

Code: [Select]

2006-01-05 21:41:13: Debug: /var/tmp/portage/wxGTK-2.6.1/work/wxWidgets-2.6.1/src/unix/baseunix.cpp(73): assert "execData.flags & wxEXEC_SYNC" failed: async execution not supported yet

Call stack:
[05] wxStackWalker::Walk(unsigned int)
[06] 0xb7c84c64
[07] 0x0805f0c1
[08] wxOnAssert(wchar_t const*, int, wchar_t const*, wchar_t const*)
[09] wxAssert(int, wchar_t const*, int, wchar_t const*, wchar_t const*)
[10] wxConsoleAppTraits::WaitForChild(wxExecuteData&)
[11] wxExecute(wchar_t**, int, wxProcess*)
[12] wxExecute(wxString const&, int, wxProcess*)
[13] 0x0805f59a
[14] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const
[15] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[16] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[17] wxEvtHandler::ProcessEvent(wxEvent&)
[18] wxEvtHandler::ProcessPendingEvents()
[19] wxAppConsole::ProcessPendingEvents()
[20] 0x08054a79

[Kry]

Execution won't work on daemon, at least async one. we have to use fork & exec on that situation, like amuleweb case.