[RejZoR]

Ok, so I've managed to set eMule in such a way that it's a portable app now. It doesn't matter where I throw its folder, it starts up as expected and loads all pre-configured settings.

Only thing that's bugging me is the "Incoming" folder sharing. And no matter what I do, eMule 050a (I've also tried eMule 0.50b BETA1) detects the presence of files in the Incoming folder, rahashes them and yet total number of Shared Files remains at 0. And if I click Reload button again, it just rehashes all the files again and again ends up with zero shared files. What's going on?

I've even tried manually adding a shared folder and then by hand changing the path in shareddir.dat to ".\Incoming" to signify a relative path and still the same behavior.

Which is odd because toolbar skins folder can be set using relative path and works just fine, but files inside Incoming folder just refuse to be shared. How can I bypass/fix this?

[xilolee]

1) Uninstall emule
2) Download binaries from sourceforge.net
3) Options extended, choose the last option (store everything in program directory), click ok, restart 2-3 times and set it.

[RejZoR]

I know that and have already done that in the very beginning. But it still won't accept relative paths for Incoming folder. I mean, it accepts it, but the odd thing is, it detects the files in the Incoming folder and even hashes them, but then doesn't consider them as shared files. It keeps on showing 0 shared files afterwards. Either I'm missing something or there is a bug with this feature.

[xilolee]

If, with relative path, you intend something like .\incoming, it seems the downloaded/completed files will be put in the incoming folder but they will not be shared.
I see them in the incoming folder, but the squares near them aren't ticked.
I have to select them all.
A beautiful dream for leechers: it's not a dream anymore, since years, it seems (click.

epsilon2, on 20 February 2010 - 08:34 PM, said:

eMule never complained about that and all seemed to work just fine. Until I noticed the rehashing session at every start up. It seems like the routine storing the hashes has problems when it encounters relative paths. All the files that got rehashed every single time where those that where added after the switch to relative path. I realized now that they also did not show up in the "Shared Files" listing. So they were hashed but after that completely ignored by eMule which also meant that their hashes were never saved.

Maybe this should be considered a bug. There could at least be some error message.

The beta file, re-created/re-shared on emule startup, isn't re-shared.
The verbose log shows only these strange lines on startup:

Quote

File shared twice, might have been a single shared file before - C:\Program Files (x86)\eMule\incoming\xxxxx.111
File shared twice, might have been a single shared file before - C:\Program Files (x86)\eMule\incoming\yyyyy.222
File shared twice, might have been a single shared file before - C:\Program Files (x86)\eMule\incoming\zzzzz.333

I agree it should be considered a bug.

[RejZoR]

Yeah, not a dream, because it works. Which is stupid. I don't want it to work! I want eMule to respect variable paths and also share files that are within Incoming folder that is defined with a variable path.

While I was waiting for the answer, I've already written an app (a portable launcher) that reads its own location, corrects the preferences.ini entries relative to its own location and then fires up emule.exe
This way I can move around eMule folder as much as I want and it'll always point to correct Incoming and Temp folders while still sharing files.

I really hope this nonsense will be fixed within eMule 0.50b, so eMule could work as portable without a launcher. But considering no one cared about this rather significant bug for this long, I don't have much hope for seeing it fixed now...

[xilolee]

Well, this passed unobserved and it isn't present in the bug reports.
Users that are using relative paths are not the majority.
I didn't even know them (rel.paths).

[RejZoR]

Well, I've always preferred single folder use. It's just easier to manage and use instead of fiddly usage of user profiles to store the settings. Relative paths are just more convenient so you can toss the folder around and it'll always work.

It just annoys me that I have to fiddle with "UsePublicUserDirectories" registry entry if I want to have it portable without modifying the binary. Which means it'll override settings for those who use eMule with settings stored in user profile and not app folder. Which is a bit annoying.

[fox88]

RejZoR, on 07 February 2016 - 11:48 PM, said:

Relative paths are just more convenient so you can toss the folder around and it'll always work.

The trouble with relative paths in general is that you must know exactly the origin.
That is, relative to what node in directory tree?
There are several ways do define the starting point.
For exmaple, it could be relative to:
- the root of the installation drive
- eMule's installation directory
- user home directory (which is already relative).

[RejZoR]

Starting point is the program EXE. Meaning it doesn't matter where you throw the program folder, paths will ALWAYS be correct. It's how I make all my stuff. It's more convenient.

[fox88]

RejZoR, on 28 February 2016 - 12:15 AM, said:

Starting point is the program EXE. Meaning it doesn't matter where you throw the program folder, paths will ALWAYS be correct. It's how I make all my stuff. It's more convenient.

That might be good enough up to XP for a single user and one drive, but hardly otherwise.
The default installation paths (see Docs, Shared Usage) might be like
..\..\Users\<Username>\Downloads\eMule\Temp.
The case with different drives and multiple directories would be even worse.