Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

Saving seems to make the SD Card unreadable on Mac and Windows. Bow Commander is the only utility I'm using at the moment other than to load via divMMC - could you look into this too please?

I have just tried to back up my .txt file to the root directory: what has happened is that the contents of text that I have written has overwritten all of the file and folder names and corrupted each of them. So the first word in my text document was `humanity` and this became the name of the first directory on the right pane.

Hi, I tried to replicate your steps and this error didn’t occur… at least not in the version of BC I’m currently using (quite a few things have been fixed in it…).

I’d also like to ask: were the files on the SD card actually (physically) damaged? Or was it just the memory that displayed the files in the panels that was corrupted?

The whole card would not read on Windows or Mac; Windows reported it as corrupt. I could read the file okay in Bow Commander, but if I could not transfer the file to Windows then this is not good for me. It was when I tried to copy the file to the root that the issue happened.

I am looking forward to the new version.

This is very strange. I only use EsxDos services for file manipulation.

(+1)

I'm actually starting to get the feeling that EsxDos isn't behaving very stably when it has to manage multiple disk operations at once..

It could also be a memory leak somewhere, or saving little and often causes issues?

I don’t really think so, because if it were a fault with Bow Commander, the disk wouldn’t be readable even in EsxDos (which you said it is). So I reckon that EsxDos does something non-standard with that volume of disk operations, which causes problems for Windows and other operating systems, but not for EsxDos itself, because it’s something it’s designed to handle...

The problem is that, until now, there hasn’t been a programme for EsxDos that would use such a large number of disk operations at once (bulk copying, deleting, etc… and I think this is where EsxDos’s bugs and lack of fine-tuning come to the fore…). I don’t mean any harm by this; nobody writes flawless programmes, but it would be good to fix this behaviour at the OS level… . 

(+1)

A friend also gave me some advice:

- Which version of EsxDos are you using? Are you using the latest version, 0.8.9?

- And which FAT are you using? 16 or 32? If it’s 16, please try 32, and if it’s 32, please try 16...

I know this probably isn’t the answer you want to hear, but this is likely a problem unrelated to Bow Commander.

I am using 0.8.9 yes. And it's FAT 32.

Could you please replicate the procedure with FAT16… if possible?