Quote from: Strofcon on July 19, 2010, 03:26:04 PM

I may be way wrong, but if you recompiled the client to use port 8339, and you're telling the modified client to connect only to localhost:8339... wouldn't that gain you very little? In other words, I'd think it would be redundant... You may want to try connecting to localhost:8333 instead...? I'm not sure, but it can't hurt! :-)

I tried running the nonmodified client that uses port 8333 to connect to the modified client that uses port 8339.

Quote from: dete on July 19, 2010, 04:51:52 PM

I'm not sure why you want to run two instances on one computer, but I can answer your question:

Initially I was unable to use Bitcoin on my computer using native linux client due to not having correct versions of libraries. I was able to get windows client to work with Wine, but occasionally it would crash. During usage of Bitcoin with Wine I had visited https://freebitcoins.appspot.com to request five free bitcoins from Gavin. However, due to many crashes I never caught up in generated blocks and didn't notice the bitcoins to appear in transaction history

Eventually I have installed latest versions of libraries in my system and was able to run a native linux client. However, I didn't immediately use the Bitcoin configuration, database or wallet files from the windows version run from Wine. Eventually I successfully compiled a version of Bitcoin to use different ports so that I could use it with my previous/initial configuration files. That was my initial intention for running two instances and I mistakenly ran both as the same user.

However, even though it may seem strange to run two instances of Bitcoin, both compiled to use different ports, perhaps there could be implemented a safeguard to prevent database access if it is currently in use, access or locked? Maybe create a lock file in /var/lock? This could prevent database corruption if a user were to run two instances of Bitcoin as same user. Currently attempting to do so with same client or a client that uses same port seems to fail nicely due to port being used. This concept should be applied to failing nicely if same database is being used also.