Xref: utzoo comp.unix.sysv386:7727 comp.unix.questions:31021
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!nstar!crom2!jim
From: jim@crom2.uucp (James P. H. Fuller)
Newsgroups: comp.unix.sysv386,comp.unix.questions
Subject: Can't copy giant file (*not* ULIMIT problem)
Message-ID: <1991May04.023545.535@crom2.uucp>
Date: 4 May 91 02:35:45 GMT
Organization: Abbey Technologies - Athens GA
Lines: 37


     I can't copy a 24-meg file without getting it truncated to 16 megs.

My ULIMIT is 73728 512-byte blocks, which should allow me to write a 36 mb
file; and anyway I'm doing this copying as root and root should be able to
write a file as big as the filesystem will hold, no matter what the ULIMIT is.
So it must be some other limit that I'm bumping into.

     The files to be copied are on filesystems that are type DOS -- that's
Interactive-speak for DOS partitions that are mounted as Unix filesystems,
which ISC SysV allows.  They were copied there originally from a CD-ROM that
will only run under true DOS and will only copy to the DOS partition.  Once
the files are on the hard disk I had expected to be able to mount the DOS
partitions under Unix as usual and then copy the files the rest of the way to
their destination in /usr4/genbank.

     This all works for the smaller files, but it doesn't work for the larger
ones like gbpri.seq, which is 24 megs of primate gene sequences in ASCII.
When I (as root) do

    # cp /dos2/genbank/gbpri.seq /usr4/genbank 

it only copies part of the file -- when the prompt comes back there's a file
called gbpri.seq in the proper place on the Unix partition but it's only
(only!) 17,208,832 bytes long where the original is 26,090,050 bytes.  There's
plenty of room (presently 135 megs free) in the /usr4 filesystem and I can't
think of any other reason why a large file shouldn't copy properly.

     Can someone please tell me what's biting me here, and what I can do about
it?  P.S. on a whim I tried cat /dos2/genbank/gbpri.seq >gbpri.seq and that
one croaked at 17,208,832 bytes also.  What's magic about that number?

                                             Thanks very much,
                                             James P. H. Fuller
                                             jim%crom2@nstar.rn.com