Definitely, user must know exactly what's going on BUT errors must not be verbose otherwise usability decreases. I suggest that when introducing such a new behaviour we should carefully think about other possible behaviours (i.e. SD being removed for some reason) and related implications, underlining the fact that we run on several different targets. Possible ideas: - design new icons for the status bar - design a new way of reporting problems to user - define error codes and human readable messages for each one - another effect can be the possibility to temporarily disable write support for debugging or whatsoever reason - define new events that can occur (also, storage may become dinamically read only for many reasons, also fatal errors on filesystem)
All in all I find these non-functional features a great deal to make Rockbox more robust ;) Lorenzo Il giorno 06/mag/2013 11:58, "Marcin Bukat" <marcin.bu...@gmail.com> ha scritto: > Failing to open file(s) for writes seems to be elegant solution but this > will probably trigger error messages as well. Moreover I think it should > trigger error message to give user feedback that card is write protected > (by accident for example). > > > 2013/5/6 Amaury Pouly <amaury.po...@gmail.com> > >> Hi , >> I'm looking for some feedback on an issue which might not be one: >> read-only storage. It appears that since virtually all DAP use micro-sd >> card we never ran into this problem but I am porting Rockbox to the >> Creative ZEN and ZEN X-Fi which feature a real SD card port and can sense >> the write-protected switch of them. >> The obvious solution is to completely ignore it of course but this is a >> bit of shame. Another option is to simply fail all writes to the storage if >> it is write protected (remember that this is completely software handled). >> I am wondering if there would be any interest in doing something a bit >> more clever, like making the file system code aware of read-only storage. >> Indeed, failing all writes will potentially stress all write path, might >> trigger bugs or obscure error messages to the user. A simple solution would >> be to prevent opening opening a file for writing for example. >> >> Any thoughts ? >> >> Amaury Pouly >> > >
