Question about ps2client.

ubergeek42 · Post by **ubergeek42** » Tue Jul 03, 2007 11:58 am

I was doing some testing, and opening a file on host as O_RDWR, results in the file being truncated, and upon looking into this a bit more, I see that in utility.c O_TRUNC is added along with O_WRONLY on line 18(in the function fix_flags). There is a FIXME comment about how some programs require this, and I was curious as to which ones, so that I know what I am breaking by removing the O_TRUNC part.

See file here:
http://svn.ps2dev.org/filedetails.php?r ... rev=0&sc=0

Post by **ooPo** » Tue Jul 03, 2007 12:29 pm

I don't remember, but it looks like a comment I'd write.

Take it out and see what happens. :)

ubergeek42 · Post by **ubergeek42** » Tue Jul 03, 2007 2:57 pm

Well taking it out makes O_RDWR work as expected, but I assumed there was probably a good reason for why it was changed that way, and just wanted to see if anyone knew of any programs that relied on that "feature", so I can avoid any possible issues with them.

ubergeek42 · Post by **ubergeek42** » Wed Jul 04, 2007 9:17 am

Sorry for the double post, but I did some more messing around with all of this:

The open flags on the ps2(in io_common.h) start at 0x0001 for read, 0x0002 for write, and 0x0003 for read/write(which means read/write is the same as O_RDONLY | O_WRONLY). On my linux computer, read is 0x0000, write is 0x0001, and read/write is 0x0002. Trying to open a file over host as read/write results in the file being opened write only. So my initial assumption that O_TRUNC was to blame, were quite off.

What is the proper way to handle this(if there is one)? And I guess I should wonder why the open flags are 1 off of what seems to be the standard on the ps2?

Post by **ooPo** » Wed Jul 04, 2007 12:11 pm

Blame Sony for the weird numbering, otherwise they wouldn't have needed to be fixed in the first place.

dlanor · Post by **dlanor** » Thu Jul 05, 2007 4:49 am

ooPo wrote:Blame Sony for the weird numbering, otherwise they wouldn't have needed to be fixed in the first place.

I don't see anything weird in using OR functions to combine separate bit flags. The only problem here is that Linux apparently doesn't use any bit flags at all, but instead uses an arbitrary constant for each 'type' of opening. So in Linux the entire method of combining bit flags for this purpose becomes unusable, and you must instead remember to use each valid type constant.

Neither method is more nor less weird than the other, and if you're just aware of which platform you're coding for, there should be no major problem adapting to it. The only problem is to write some generic code that will work on either platform. This may best be dealt with by some preprocessor '#ifdef' clauses identifying the platform type.

Best regards: dlanor