When trying to delete a corrupted file on SD card the File.Delete(“corruptedFile.txt”) method will freeze all threads that are running in application. Even if I make the call from a worker thread.
The call never returns so we got a deadlock.
Any idea how to safely delete files that are corrupted?
Format maybe?
Format is not always a solution.
If the device is hundreds of Kilometers away, and a file got corrupted (power down during write process for example), you might just want to delete the file from the SD Card by application (or from PC via FTP).
A freezing device in this case is a real worst case scenario.
I had problems like not being able to write any more files to a specific folder, which is also also quite bad.
According to my own experience and what I read so far in the forum I think GHI should check if the SD card driver could be improved in a way, that corrupted files on SD card can be handled in some way or avoid corruption (by power down,…) completely if possible.
The goal in my project was to write log files.
Keeping the log file handle open and flushing the text writer after each line gave me good performance, but when I reset the device, the files or part of it was not there after reboot. In some cases I had a corrupted file system (at least the log folder was not usable anymore.
Then I changed it to open the file for every log message and close it afterwards.
By this the file was written correctly but It used up so much processing time that the application itself was not working anymore (a lot of timing issues, slow response on ethernet).
I’ve been using a custom G120 board with ENC28 and SD card reference design as well as G120HDR with GHI modules.
I had about 30 log messages (<80 chars each) every 60 seconds.
Currently I have disabled writing log files to SD card.
My suggestions for using SD cards at the moment:
Read only: OK 
Write sometimes, read often: Works if you make sure there is no power down and files get flushed correctly after writing. ???
Read/write all the time: Currently a no go, quite risky. 
@ Reinhard Ostermeier -
I totally agree with you.
We have the exact same problem and also need to have a open file stream for log performance.
We will inform Microsoft about this and if you like open an issue on codeplex so it is always there. Post back so community can vote please.
I believe its better to make sure that corruption can’t happen due to power loss. Every computer / micro controller that writes to whatever type memory might might be effected when power goes down half way a write cycle. A battery back up might save a lot of troubles.
Hi,
Im also just having proplems with the SD-Card in my bluetooth file transfer application (see Codeshare Section). Mostly in larger files of more than 1 MByte the application on the spider, where data are written to the SD-Card in chunks of around 2 kByte, sometimes crashes and and the spider mainboard reboots. This occurs mostly when more than 200 chunks are written to the SD-Card. When I tried to use the filestream.flush() command after each chunk of data, the application alwayws crashed after a few chunks. Then, when I took two other modules which were connected to the spider, away, the application run without crashes. So I think, that the reason for the problem could be spikes on the 3.3 V power line on the mainboard. I can imagine, that when the buffer is flushed, the burst of signals could pull down the power, which makes the mainboard to reboot. As a next step Ill try to solder an additional capacitor on the power line of the SD-Card Module. Did anyone yet survey the powerline of mainboard and SD-Card module for short downbreaks of power?
Regards
Roland
No but it goes higher on the list because many might think it’s urgent…
Hi,
it’s not exactly the topic of this thread, but I want to tell that the reason for my issue in post #6 was a bad ribbon cable from power module to the mainboard. Took me some hours to find it. May be it is better to solder a cable from mainbord to power module for Gnd and 3.3 Volt line.