o------------------------------------------------------------------------------o
| Processing INI Settings
/ does not existirectory directory /home/uox3/server/
o------------------------------------------------------------------------------o
Giwo, would you like access to my server to play with it? I'm fearing that I am missing some warning during compilation (it spits out a BUNCH).
We know it's reading the ini, as it changed the path it spits out (that it sees as invalid). What I don't understand is why it can't open that directory.
Really I think we need someone with more *nix experience to offer some thoughts/suggestions on why it won't recognize the directory. Based on the linux programming sites I looked into, that usage of opendir() should be fine.
Moreover, GhostTyper, a linux user posting in another forum, seems to have no trouble getting the server running (once we got past the compile errors) he is getting a crash when logging in.
I remember experiencing the same problems with the directories after I compiled it, hence my comment on getting it to work is actually trickier than compiling it. I don't actually remember the fix to it unfortunately.
Try printing out what is contained in sText.c_str() (that which is passed into opendir() )- I believe it did some windows-only directory path translation before that actual code?
Add
printf("\n\nPath : %s\n\n", sText.c_str());
before the DIR *dirPtr etc. and see what it comes out with.
Last edited by xir on Sat Oct 08, 2005 1:56 am, edited 1 time in total.
xir: That's actually why I had him comment out the entire statement inside the #if, as uoxlinux.h will actually wrap those function calls (thus causing you to not need #ifdef'd code). However even when using that method, it wouldn't work.
if may also be worth noting that display errors such as:
/ath
and
/ does not existirectory directory
Have nothing to do with the problem, but are caused by how the messageloop vs direct console access interact (sometimes interfering with eachother).
Ok then. The problem still has to be what is being passed in as the parameter right? There *could* be a carriage return character embedded in the actual string at the end of the sText.c_str(). Going on a wild guess here. But try this
That is an unnecessary step, unless on did not properly ensure the text files have the unix end of line (versus the windows). When one unzipped, if the -a option was used (for the zip file was made on windows), it would convert the text files to unix end of line format. In addition, there are dos2unix utilities available to convert them files (which I personally would recommend over changing code, ensuring the data files are consistent with the OS they are on).
It probably isn't an issue but paste the previous bit of code I pasted into the place of that last print and see what it comes out with. There most be *something* not correct with what is being passed in.