forums.ps2dev.org

J-Fox · Joined: 26 Sep 2007 Posts: 15 Location: Hannover, Germany

I just noticed that there seems to be some problem with "sceIoDread" on 3.71M33 .
Somehow it skips some files or uses an outdated filesystem. It appears to do this randomly. On 1.50 this seems to work like icecream but on 3.71M33 its pretty buggy for some odd reason.

in 7/10 cases it didnt load up the whole directory in my test.

I created a directory: LOG on the root of the memorystick, in my application it was not visible (sceIoDread). It saved the logs to exactly that directory and it looked fine on USB. However, i removed the directory via USB and tada - on the next startup it showed up in my application - however, writing the log failed cause the directory didnt exist anymore. I left the directory and it was gone again. Then i looked into PSP/Game and it was empty. Back in USB mode it had 2 files and 5 directorys.

I doubt its any bug in my code. Seeing that it works fine sometimes and its also working on 1.50 without problems.

Jim · Joined: 02 Jul 2005 Posts: 487 Location: Sydney

Try memsetting the dirent structure to 0 before calling.

Jim
_________________
http://www.dbfinteractive.com

J-Fox · Joined: 26 Sep 2007 Posts: 15 Location: Hannover, Germany

Thats what i did. It works fine under the old PSP on 3.71M33 and 1.50, but it fails often on the Slim with 3.71M33.

//Edit: re-assigning the device and/or replugging the memory stick after changes to the files / directorys seems to fix the problem btw.

Hellcat · Joined: 24 Jan 2007 Posts: 84

No need to re-assign the device, just clear/invalidate the cache.

I assume you're makeing changes on your MS via USB while your app runns?
Common cause for memstick curruption, BTW ;)

J.F. · Joined: 22 Feb 2004 Posts: 2906

Sounds like you're running into the same problem people did when running Mac emulators - trying to make the Mac volume accessible to the emulator and the host at the same time could lead to corruption. The emulator (running the MacOS) had its own filesystem buffers with info on the volume, while the host OS had its own filesystem buffers with info on the volume. Changing one without flushing the buffers on the other would lead to corruption. You have to flush one to make sure its data is all written out, flush the other to make sure it has the latest info, have the other do its changes, have the other flush its data out to the volume, then flush the first again to make it use the changes made by the other. Big pain in the rear. If you forget one of the flushes, you wound up with stale data and corruption.