[openbeos] Re: Large File Woes
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 05 Jul 2004 14:55:45 -0700
Not sure, but makeudfimage is using BFile, which ought not be broken.
-Tyler
On 2004-07-05 at 14:47:22 [-0700], François Revol wrote:
> Does cat use the FILE* funcs ?
> I noticed in R5 one of them was broken:
> (from my PearPC port):
>
> FileOfs sys_ftell(SYS_FILE *file)
> {
> fpos_t pos;
> int err;
>
> // BeOS *is* 64 bits :p
> // ftell and fseek use long !! whoever invented the buffered io stuff
> should be
> slapped :^)
> // _fseek does work, but not _ftell... use _fgetpos
>
> err = fgetpos((FILE *)file, &pos);
> if (err < 0)
> return err;
> return pos;
> }
>
> Maybe cat uses it and borks?
>
> François.
>
> Selon Tyler Dauwalder <tyler@xxxxxxxxxxxxx>:
>
> > I've been working on large image support for UDF, and I've run into an
> > interesting problem. I'm trying to make a udf image of my home directory,
> > which is 5 or 6 GB large. I've done this before and created images about
> > 4GB large, but with my recent attempts, I'm getting B_DEVICE_FULL errors
> > from the operating system when I get to about 1.25GB. The device is in
> > fact, however, not full.
> >
> > I then created a test program which just writes a simple string of data
> > over and over to a given file using either open()/write() or
> > BFile()/BFile::Write(), and both versions successfully create images
> > larger
> > than 1.25GB.
> >
> > The really interesting part comes when I try to append data to the end of
> > these large files. In the listing below, home.udf is the udf image file I
> > was attempting to create with makeudfimage, bfile.udf is the random-data
> > file created via BFile, and open.udf is the random-data file created via
> > open()/write(). As you can see, I can append data to the two random-data
> > files (I killed the cat with ^C after a few seconds), but attempting to
> > append data to home.udf craps out with a B_DEVICE_FULL error (despite the
> > fact I have over 1GB free on the drive, still).
> >
> > --------------------------------------------------------------
> > /boot $ ll
> > total 5639371
> > drwxr-xr-x 1 baron users 4096 Jul 5 13:08 apps
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 beos
> > -rws--sr-- 1 baron users 1615000000 Jul 5 14:16 bfile.udf
> > drwxr-xr-x 1 baron users 2048 Jan 19 19:20 biggg
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 demos
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 develop
> > drwxr-xr-x 1 baron users 5120 Jul 5 14:13 home
> > -rw-r--r-- 1 baron users 1343551488 Jul 5 13:59 home.udf
> > -r-S--Sr-- 1 baron users 2816141120 Jul 5 13:59 open.udf
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 optional
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 preferences
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 var
> > /boot $ cat ~/Desktop/desktop.udf >> ./bfile.udf
> >
> > /boot $ cat ~/Desktop/desktop.udf >> ./open.udf
> >
> > /boot $ cat ~/Desktop/desktop.udf >> ./home.udf
> > /bin/cat: write error: No space left on device
> > /boot $ cat ~/Desktop/desktop.udf >> ./open.udf
> >
> > /boot $ ll
> > total 5146677
> > drwxr-xr-x 1 baron users 4096 Jul 5 13:08 apps
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 beos
> > -rws--sr-- 1 baron users 1621094848 Jul 5 14:16 bfile.udf
> > drwxr-xr-x 1 baron users 2048 Jan 19 19:20 biggg
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 demos
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 develop
> > drwxr-xr-x 1 baron users 5120 Jul 5 14:13 home
> > -rw-r--r-- 1 baron users 1343551488 Jul 5 13:59 home.udf
> > -r-S--Sr-- 1 baron users 2827151168 Jul 5 14:17 open.udf
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 optional
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 preferences
> > drwxr-xr-x 1 baron users 2048 Aug 24 2003 var
> > /boot $
> >
> > ----------------------------------------------------------------
> >
> > Any ideas what the problem could be?
> >
> > -Tyler
> >
>
Other related posts:
