Rockbox mail archive
Subject: Potential "*PANIC* Update fat entry 0" message when calling "fat_truncate"
From: Christophe Avoinne (christophe.avoinne_at_laposte.net)
----- Original Message -----
From: "Paul van der Heu" <pvdh_at_xs4all.nl>
Sent: Thursday, November 14, 2002 9:29 PM
Subject: Re: Recording woes (in detail)
> >2) What happens when changing "RECORDER.MP3" for another shortname ?
> >must we delete it before having another "*PANIC*" ?
> how do you mean? if I rename RECORD.MP3 to TEST.MP3 and record I get
> the panic..
I mean changing "RECORDED.MP3" in the rockbox source so after recompiling,
it can create and record with a different name that "RECORDED.MP3". So the
very first time when you try to record, you are sure there is no deleted
entries matching the filename except for the first character. Do you have a
I want to know whether you need at least that the file is created even if it
is empty (filesize is zero) to be able to record. If so, it would mean the
"create" operation might be not totally working and there is something which
provokes that *PANIC* message (occurs in function "update_fat_entry").
Actually, looking at "write_next_cluster" (called by "fat_readwrite") code
shows no potential "*PANIC*" message.
But there are two other functions calling that function : "fat_truncate" and
When recording, we call "open" with O_WRONLY|O_TRUNC|O_CREAT, so we are sure
that "fat_truncate" and "fat_closewrite" would be called. But they are
called at the end of the recording (i.e, when pressing OFF).
Looking at "fat_closewrite" code shows no potential "*PANIC*" messages.
Looking at "fat_truncate" code shows there are no checking for the last call
"update_fat_entry (file->last_cluster,FAT_EOF_MARK);", so there are
potential "*PANIC*" messages at this point. Indeed, I think it may be the
bug we chase : if "file->last_cluster" equals to 0, we shouldn't call the
function "update_fat_entry" since we must never touch the fat entry 0.
Page was last modified "Jan 10 2012" The Rockbox Crew