Rockbox mail archive
Subject: Re: Recording woes (in detail)
From: Christophe Avoinne (christophe.avoinne_at_laposte.net)
> However I am asuming it is not the delete action by windows which
> creates the filesystem error, but the way rockbox opens a new file.
> As the error is easily recreated by either deleting the RECORD.MP3
> file though windows and then recording again or renaming the
> RECORD.MP3 and recording again.. Either way the result is that
> rockbox panics..
> If I then just restart rockbox and start another recording (with the
> 0byte RECORD.MP3 file left alone by me) there is no error..
I think Windows deletes one entry and create another entry when renaming a
file or directory. So the problem should be the same as for deleting when
The facts : you delete the file, so Windows marks the entry as deleted, just
by marking the first chararcter with the special deleted character, not
touching anything else. But when Rockbox starts recording, while creating
the file (BTW, we don't know if it takes the deleted entry back), you always
get a "*PANIC* Updating reserved FAT entry 0", which is an attempt to append
a new cluster to a cluster chain starting at the reserved cluster 0,
something obviously forbidden.
1) Does it happens at once (at the very first cluster writing of the file)
or just after several cluster writings ?
2) What happens when changing "RECORDER.MP3" for another shortname ? must we
delete it before having another "*PANIC*" ?
3) I suppose you don't keep some pertinent infos about RECORDED.MP3 like its
start entry even after a power-off ? because if so, the next cluster
following the start cluster for the deleted RECORDED.MP3 would be 0.
Calling "write"... calling "fat_readwrite"... calling "next_write_cluster"
with parameter "cluster" being 0... humm calling "update_fat_entry" only
happens if allocating a free cluster is successful, so I don't see how we
can have the message "*PANIC* Updating reserved FAT entry 0" :/. weird...
Page was last modified "Jan 10 2012" The Rockbox Crew