Re: JFFS2 (ecos) broken

Hello,

attached is a log-file corresponding to the source code below plus two "ls" 
commands after closing. In the log you can see, that the filesize changes after 
the garbage collection that is triggered (?) by the second ls.

You are right, it is just test code, but my main point is not the write loop, 
but the lseek command that finally fails.

Regards,
Dirk

-------- Original Message --------
Subject: Re: JFFS2 (ecos) broken (31-Mrz-2004 12:22)
From:    [email protected]
To:      [email protected]

> On Wed, 2004-03-31 at 06:08 +0000, [email protected] wrote:
> > Sorry to contact you directly, but I have sent the following mail to jffs-
> > [email protected]
> 
> Rejected because your lines are too long? :)
> 
> > I am using ecos JFFS2 (latest cvs) and have a problem, that maybe has been 
> > already s
> > 
> > When I set the cursor to a point in a file (using e.g. fseek) and perform a 
> > write th
> > 
> > Here is a little code to reproduce that:
> > 
> > 	if (( fp = fopen(FILEN, "w")) == NULL) {
> > 		diag_printf("fault\n");
> > 	}
> > 	else  {
> > 		char c = 0;
> > 		for (int k=0; k < 4096; ++k)
> > 			fwrite(&c, 1, 1, fp);
> > 		stat = fseek(fp, 512, SEEK_SET);
> > 		fputs("End\n", fp);
> > 		fclose(fp);
> > 	}
> > 
> > After a reboot you can see, that the file size is only 522 bytes and not 
> > 4096 as it 
> 
> That's odd. Can you set CYGOPT_FS_JFFS2_DEBUG to '1' and show me the
> _complete_ output during your test run, and on the subsequent mount?
> 
> I assume you realise that you're triggering worst-case behaviour from
> JFFS2 by writing a single byte at a time, and this is just a test?
> 
> -- 
> dwmw2
> 
> 
> 
> 
> To: [email protected]
> Cc: [email protected]


To: [email protected]
Cc: [email protected]