PSP SDK File IO bug(s)

[SANiK]

Ok, I did a series of tests, and here they are:

1) Testing sceIoOpen with \ and / paths:
Worked:

Code: Select all

sceIoOpen("ms0:\\debug.txt", PSP_O_APPEND | PSP_O_CREAT | PSP_O_WRONLY, 0777);

Worked:

Code: Select all

sceIoOpen("ms0:/debug.txt", PSP_O_APPEND | PSP_O_CREAT | PSP_O_WRONLY, 0777);

2) Testing -lpsplibc's fopen with \ and / paths:
Worked only if file already exists:

Code: Select all

fopen("ms0:\\debug.txt", "a");

Worked only if file already exists:

Code: Select all

fopen("ms0:/debug.txt", "a");

Why do I say worked only if file already exists?
If you check psplibc's fopen code:
http://svn.ps2dev.org/filedetails.php?r ... rev=0&sc=0

Under the "a", there's only:

Code: Select all

case 'a':
          flag = _IORW;
          iomode = PSP_O_APPEND;
          break;

When it really should be:

Code: Select all

case 'a':
          flag = _IORW;
          iomode = PSP_O_APPEND | PSP_O_CREAT | PSP_O_WRONLY;
          break;

This means the above fopen would only work if the file's already created.
(But all write attempts would fail due to the missing PSP_O_WRONLY)


3) Testing -lc's (newlib's) fopen with \ and / paths:
Failed:

Code: Select all

fopen("ms0:\\debug.txt", "a");

Worked:

Code: Select all

fopen("ms0:/debug.txt", "a");

4) The PSP is not Linux, so I don't know why the majority of the lib writers are trying to make it be.

sceIoOpen("/Data/debug.txt", ...);
This checks for folder 'Data' in the current directory

Doing the same using fopen() would fail because you guys keep processing '/' as if it were the root dir.

A fix would be to make '/' be the current EBOOT path, like how sceIo does it

-----------------------------------------
Summary:
1) Add support for \ in newlib's fopen
2) Fix 'a' mode in -lpsplibc's fopen
3) "/debug/debug.txt" != "debug/debug.txt", when it should be ==

[ITDemo]

wow! This is really interesting!
So.. any volunteers to fix it?

[J.F.]

4) The PSP is not Linux, so I don't know why the majority of the lib writers are trying to make it be.

sceIoOpen("/Data/debug.txt", ...);
This checks for folder 'Data' in the current directory

Doing the same using fopen() would fail because you guys keep processing '/' as if it were the root dir.

A fix would be to make '/' be the current EBOOT path, like how sceIo does it

-----------------------------------------
Summary:
1) Add support for \ in newlib's fopen
2) Fix 'a' mode in -lpsplibc's fopen
3) "/debug/debug.txt" != "debug/debug.txt", when it should be ==

You're the one confused... libc is designed for POSIX systems. POSIX is a API that's not exclusive to linux - linux is merely one of MANY systems that use the POSIX standard. You're talking about adding code to take the system further from POSIX just to make it easier on Windows programmers who have probably never even heard of POSIX. Your #1 in particular is a crutch for lazy Windows writers. #2 is a bug and should be fixed. #3 is not a bug, it's part of POSIX; as such, it doesn't need changing.

[SANiK]

4) The PSP is not Linux, so I don't know why the majority of the lib writers are trying to make it be.

sceIoOpen("/Data/debug.txt", ...);
This checks for folder 'Data' in the current directory

Doing the same using fopen() would fail because you guys keep processing '/' as if it were the root dir.

A fix would be to make '/' be the current EBOOT path, like how sceIo does it

-----------------------------------------
Summary:
1) Add support for \ in newlib's fopen
2) Fix 'a' mode in -lpsplibc's fopen
3) "/debug/debug.txt" != "debug/debug.txt", when it should be ==

You're the one confused... libc is designed for POSIX systems. POSIX is a API that's not exclusive to linux - linux is merely one of MANY systems that use the POSIX standard. You're talking about adding code to take the system further from POSIX just to make it easier on Windows programmers who have probably never even heard of POSIX. Your #1 in particular is a crutch for lazy Windows writers. #2 is a bug and should be fixed. #3 is not a bug, it's part of POSIX; as such, it doesn't need changing.

1) I know what POSIX is

2) If you're a POSIX fanboy, then why aren't you busy implementing case sensitivity into file paths?

Since you know, "ms0:/psp/" != "ms0:/PSP/"
(according to POSIX)

3) I'd also like to see you remove use of "ms0:/" and "umd0:/" in favour of "/ms0/"

4) Get where I'm going with this?

If you want to treat the PSP as a POSIX machine, then fully implement POSIX.
Otherwise, your words have no meaning to me.

My request for support of '\\' and root ('/') being relocated to the current EBOOT folder still stands.

This is how sceIoOpen does it, this is how I think fopen() should do it as well.

[TyRaNiD]

Geez you are in a pissy mood.

Yah the bug in pspsdk libc is a real bug but so what, that libc has been deprecated for ages, tbh I wish I had removed the damn thing years ago.

As for differences between fopen and sceIo I think you are just moaning. I don't think there was ever any sort of decision to say fuck you to people wanting to use back slashes, just it was simpler not to handle them as in reality the code in the libc is trying to emulate a more consistent set of directory operations which sony didn't really implement. I don't see it as a massive missing feature which requires a rather vitriolic post about.

And as for / meaning the EBOOT directory I personally think that is a bug, at least from fopen's point of view (it should be so in sceIo as well :P). The primary reason to use fopen is for porting, you could complain that the use of only forward slashes is a limitation on porting windows crap, but hey guess what, porting windows stuff with backslash paths to *nix won't get you far either. As fopen is for compat then it is meant to reflect a consistent file system, you wouldn't expect the use of the drive prefixes at all in a "normal" application anyway so the root slash crap makes zero sense. And as for case sensitivity that is a limitation of the FAT driver (and FAT is general) which cannot always guarantee case preserving behaviour. My hostfs driver has no such problems when run on a case sensitive system, of course you can add a compatibility option to help with "broken" applications.

If you like Sony syntax then by all means use sceIoOpen then fdopen to get the... oh wait you can't cause the file descriptor returned by native functions might not match what newlib uses due to "hacks" to make a consistent file descriptor setup. Should I file another bug report?

[SANiK]

Did I mention that I love you TyRaNiD?

In a non-gay way of course.

I understand that fopen is intended to aid porting, and you have a point about using sceIoOpen, but if fopen fails to support \\ let's say, then it's crippling the porting of Mingw based apps.

I came across this 'lack of \\ nuisance' by porting code from mingw and running it under PSPLink.

PSPLink uses its own hooks, and the hooks supported \\

Well, then I compiled as an Eboot, ran it, but no go.

A global replace of \\ to / fixed the issue, but it did take a while to figure out what the hell was wrong.

[J.F.]

I won't respond to the rest, but POSIX doesn't require case sensitivity to paths - that's part of the FILESYSTEM, not POSIX. :P

Other than that, TyRaNiD's response covers it all nicely. Look, I can understand where you're coming from, I just don't think it's worth the effort for more than the bug-fix. I suppose you could work on the \\ support yourself... I won't complain, I just won't help. :)

[SANiK]

I guess we came to a great ending.

But,

I won't respond to the rest, but POSIX doesn't require case sensitivity to paths - that's part of the FILESYSTEM, not POSIX. :P

According to POSIX section A.4.6, "case folding" is prohibited.
http://www.opengroup.org/onlinepubs/000 ... g_01_04_06

The consensus selected the first proposal:
Remove all wording that previously permitted case folding.

Case folding ... is, treating uppercase and lowercase alphabetic characters as identical.

(Initially, a list is given of why case insensitivity should be used, but the final ruling is to be case sensitive)

;)

[J.F.]

I guess we came to a great ending.

But,

I won't respond to the rest, but POSIX doesn't require case sensitivity to paths - that's part of the FILESYSTEM, not POSIX. :P

According to POSIX section A.4.6, "case folding" is prohibited.
http://www.opengroup.org/onlinepubs/000 ... g_01_04_06

The consensus selected the first proposal:
Remove all wording that previously permitted case folding.

Case folding ... is, treating uppercase and lowercase alphabetic characters as identical.

(Initially, a list is given of why case insensitivity should be used, but the final ruling is to be case sensitive)

;)

Well what do you know, you're right! Thanks for pointing that out. I goofed on that one. :D

[TyRaNiD]

So PSPLink supports \\ inside fopen calls? That would be an interesting thing as I am not sure how that would work :) Certainly hostfs supports backslashes cause some code uses it and the kernel just hands off stuff the original path to hostfs (so it gets converted on the PC side). But so does the ms driver therefore ...

It could of course be argued that any code which uses either backslash or forward slash directly is non-portable anyway (I know my code is :P)