True, but as the delay prevents errors on the slow cards we can't do without it...
Perhaps we should change that. For some odd reason the size read is not necessarily correct while browsing an MC anyway. As you know, if we delete or paste something, the size is NOT updated correctly, nor is that done if we enter a subfolder, nor when we 'back out' of that again.
The function is called each time a directory is changed on the mc in the fileBrowser so there is a delay each time.
The only way we get changed size correctly displayed, is if we back out to the top level of the browser, and again choose that MC. We should either correct that (somehow ;)), or remove the inefficient space checks.
True, but my delay is more on the order of one second or slightly less, though it gets a little longer than one second for the card that is nearly full.
You can really see a difference in response time without the get mcfreeSpace. You too will most likely notice the difference with your 32MB cards.
Do you mean using the fioGetstat call for that folder pathname ?
On the topic of memory cards, I noticed something else a few days ago. In the process of trying to understand where the size using fio stat.size on mc folders comes from,
If so, that should be easy to check by modifying my earlier patches to the 'Get Size' command. I'll get on it and see what I can find out too.
Interesting, this implies that some additional function is needed to enforce an update of such things.
I found out that the size tells how many files/directories are within a given directory plus two("." and ".."). My BADATA-SYSTEM directory kept throwing me off though as it had a size of 34 and I only had 5 files in it. Then I remembered that I used that same directory to test timestamps months before with multiple files although I had already deleted all those files a long time ago.
This is all very interesting, and I'll start some experiments on this myself. In any case, it is fortunate that mcPaste has been completed, as this allows full defragmentation of a card without risk of losing saves.
Eventually I found out that deleting a file alone wouldn't free up its allocated space. The size of the directory shown with fio stat.size didn't change after deleting files from the directory. The directory apparently had already allocated the space for the card and the only way to clear it was to delete the whole directory. I ended up with about 40KB more space by doing this after restoring the directory and it's 5 files. The directory currently shows up as having a size of 7(5 files + 2) with fio stat.size.
Ok, but one crucial point here is if the reserved space is related to the size of the files themselves (which could be huge !!!) or if it merely represents a 'placeholder' for the MC directory management. I think it's just a placeholder, as we would otherwise have noticed it long ago.
So deleting files alone won't free up all the space you have to remove the entire directory as well. It's fairly easy to see how memory cards can get fragmented with ps2 homebrew. The fio stat.size shows the maximum number of files/directories that were in a given directory. It must only expand the fio stat.size when files/directories are only added not when they're removed.
Another important factor is whether or not the reserved space will in fact be reused for new files or not. Putting it differently: does the driver regard the file count as being merely what it has reserved for the usage of that folder, or does it regard those entries to still be in actual use (though the files are gone) ???
In the first case, the fragmentation loss would not be 'fatal', but in the second case it would be. This needs to be thouroughly tested.
Best regards: dlanor