Rockbox mail archiveSubject: Re: Handling of read-only storage: feeback wanted
Re: Handling of read-only storage: feeback wanted
From: Lorenzo Miori <memorys60_at_gmail.com>
Date: Mon, 6 May 2013 13:22:56 +0200
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.
- 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 ;)
Il giorno 06/mag/2013 11:58, "Marcin Bukat" <marcin.bukat_at_gmail.com> ha
> 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.pouly_at_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
Received on 2013-05-06