file i/o troubles

Joel Sherrill joel.sherrill at OARcorp.com
Tue Apr 24 21:36:17 UTC 2001


Andrew Bythell wrote:
> 
> Hi -
> 
> Attached is a sample application that demonstrates the problem.

Ahhh.... test cases. :)

This was an interesting artifact of the file descriptors
not being completely reinitialized.  The fix was 1 line 
to memfile_open to set the file size field in the 
libio structure.  I also took the liberty to modify
rtems_libio_allocate() to clear out offset and size 
to remove the now redundant iop->offset=0 from open().

The tftp and any other filesystems need to be updated to
set the file size in their open handler.  I do not know
how to do this for tftp.

Thanks for the bug report.  It took a nice example to test it.

--joel
 
> Andrew.
> 
> jennifer averett wrote:
> >
> > Do you have a complete test that shows this problem that you
> > could submit?  It is much easer to reproduce and
> > fix problems that way.
> >
> > Thanks
> > Jennifer
> >
> > Andrew Bythell wrote:
> >
> > > Hello -
> > >
> > > I am seeing strange behaviour when writing to files using the IMFS and
> > > rtems-ss-20010326.  I had this same problem with earlier snapshots too.
> > > Consider:
> > >
> > > FILE *fp = fopen("somefile", "w");
> > > fprintf(fp, "line1\n");
> > > fclose();
> > > fp = fopen("somefile", "a");
> > > fprintf("fp, "line2\n");
> > > fclose();
> > >
> > > The first time I call this routine, 'somefile' is created and contains:
> > >
> > > line1
> > > line2
> > >
> > > which is fine.  Subsequent calls, using the same or different filename,
> > > insert junk (NULL characters) between line1 and line2:
> > >
> > > line1
> > > ^@^@^@^@^@^@...
> > > line2
> > >
> > > Can anyone offer an explanation and/or solution?
> > >
> > > --
> > > Andrew Bythell
> > > Nortel Networks    System Verification
> > > Ottawa, Ontario Canada    esn.39.56930
> > > tel.613.765-6930      fax.613.763-7795
> 
>   ------------------------------------------------------------------------
>                    Name: ftest.tar.gz
>    ftest.tar.gz    Type: GNU Zip (application/x-gzip)
>                Encoding: base64

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985
-------------- next part --------------
Index: c/src/lib/libc/libio.c
===================================================================
RCS file: /usr1/CVS/rtems/c/src/lib/libc/libio.c,v
retrieving revision 1.35
diff -u -r1.35 libio.c
--- c/src/lib/libc/libio.c	2001/01/08 18:26:44	1.35
+++ c/src/lib/libc/libio.c	2001/04/24 21:50:11
@@ -208,6 +208,8 @@
     rtems_libio_iop_freelist = iop->data1;
     iop->data1 = 0;
     iop->flags = LIBIO_FLAGS_OPEN;
+    iop->size = 0;
+    iop->offset = 0;
     goto done;
   }
   
Index: c/src/lib/libc/open.c
===================================================================
RCS file: /usr1/CVS/rtems/c/src/lib/libc/open.c,v
retrieving revision 1.9
diff -u -r1.9 open.c
--- c/src/lib/libc/open.c	2001/01/08 18:26:44	1.9
+++ c/src/lib/libc/open.c	2001/04/24 21:50:11
@@ -146,7 +146,6 @@
    *  returned by successful path evaluation.
    */
 
-  iop->offset     = 0;
   iop->handlers   = loc.handlers;
   iop->file_info  = loc.node_access;
   iop->flags     |= rtems_libio_fcntl_flags( flags );
Index: c/src/libfs/src/imfs/memfile.c
===================================================================
RCS file: /usr1/CVS/rtems/c/src/libfs/src/imfs/memfile.c,v
retrieving revision 1.14
diff -u -r1.14 memfile.c
--- c/src/libfs/src/imfs/memfile.c	2001/03/23 14:02:02	1.14
+++ c/src/libfs/src/imfs/memfile.c	2001/04/24 21:50:22
@@ -98,6 +98,7 @@
   if (iop->flags & LIBIO_FLAGS_APPEND)
     iop->offset = the_jnode->info.file.size;
 
+  iop->size = the_jnode->info.file.size;
   return 0;
 }
 


More information about the users mailing list