Cannot safely use subdirs in data dir with C api

SDK Bug Reports
1

I've found the file api quite confusing to the point I think the behaviour I see might be some kind of bug.

Docs.

Basically we have a few facts:

  • There are two file locations accessible with the API on disk - /Games/<name>.pdx/ and /Data/<bundleid> dir
  • Reads read from the pdx unless kFileRead | kFileReadData is used
  • Writes always acts on the Data location

listfiles and stat read so we can assume they act on the pdx, while mkdir, unlink and rename write so must act on data. This caused me some confusion - writing a file and attempting to stat it, for instance.

This causes some "technically impossible" usage, e.g. mkdir errors when it tries to create a directory that already exists, but neither stat nor listfiles can be used to check. So how can one effectively use mkdir without just ignoring it's errors?

I'm wondering if this can be considered a bug? Perhaps it's simply a feature request though.

Edit: Worth noting a potential bug here was on Windows in the simulator - a file write into a data subdir automatically created the directories, but on device it errors.

Edit 2: A first step fix to the current API could just be to make mkdir behave like an mkdir -p (e.g. create a full path, and don't error any part already exists).

2

I'm certain you can call stat on a dir. it will have the isdir field set to 1 and the timestamp of creation. (I use this in a couple of my games.)

Worth noting a potential bug here was on Windows in the simulator - a file write into a data subdir automatically created the directories, but on device it errors.

That does seem like a mismatch in behavior. I don't blind write into a dir so I haven't come across this.

A first step fix to the current API could just be to make mkdir behave like an mkdir -p (e.g. create a full path, and don't error any part already exists).

I believe we should to continue error on trying to make a directory that already exists. You can get why it failed with geterr.

You can shoot yourself in the foot with stat if you have a directory/file in your pdx with the same name as the data folder, as it will return the data folder directory/file instead of the one in the pdx. Which it would be nice to specify where you want to look.

3

Ah thanks, I'll experiment a little more - maybe stat operates in kFileRead | kFileReadData mode then. For me it wasn't doing that - I'd call mkdir and then the stat afterwards would fail immediately.

4

Just to confirm - yup looks like stat does behave as described by @DraperDanMan and will prefer data dir files over pdx file.

Good to know for sure, but still makes stat unable to be used to "safely" check if a data file exists on the chance it might be returning you the pdx file.

I've reported another bug that highlights this here, where you can't stat to check before an unlink .