Very Computer

I have a large file (2476740 bytes) that I want to copy to another
file system. after copying 2097152 bytes the system complains about the
size of the file  core dumps.

Is there a way to do it?

OS:  UNIX System V/386 Release 4.0 Version 3.0
Hardwere: iSBC486 133SE

                                        Thanks
--
                                        Yair Friedman.

Look into BSDI or 386BSD or Linux, eh? :)
--

  Custom UNIX software and networking solutions.
  All statements contained herein might be accurate, but may also be carefully
  constructed lies designed to induce an angry response.

The problem is undoubtedly the maximum filesize resource limit.  The
first thing to do is to look in /etc/conf/cf.d/mtune and see what
SFSZLIM and HFSZLIM are set to.  The default on my (ESIX 4.0.3) system
was 0x200000, or 2097152 bytes.  I believe this is the way USL ships the
code base, so this isn't ESIX-specific.  Edit /etc/conf/cf.d/stune and
add the lines:

        SFSZLIM         0x7FFFFFFF
        HFSZLIM         0x7FFFFFFF

then rebuild your kernel.  "0x7FFFFFFF" means "infinity" for a resource
limit.

Next, edit /etc/default/login and add (or change) the ULIMIT line:

        ULIMIT=999999

or some other suitably large value (in blocks).

Reboot, and your problems should be solved; if not, check the /etc/rc?.d/*
files and other such places for a resource limit directive.

                -Ed Hall

Quote:>I have a large file (2476740 bytes) that I want to copy to another
>file system. after copying 2097152 bytes the system complains about the
>size of the file  core dumps.

the parameter you want to adjust is:

either HFSZLIM or SFSZLIM then rebuild and relink your kernel.

RTFM!

                        Jeff

David
--
------------------------------------------------------------------------------

 School of Physics, University of Sydney, Australia   | Fax:   +61 2 660 2903
------------------------------------------------------------------------------

                -Ed Hall

Since root is the only user that can move the ulimit higher you
can change it on a per process basis - so that if you are using
ulimit to save the system in the even of a runaway process you
can leave the limit where it is and raise it selectively.

In my cron I have a few overides - particularly for news -
whose history file likes to get big.  You can do this

30 1 * * * (ulimit 6000; /bin/su news -c '/usr/lib/newsbin/expire/doexpire ')

Since root can up the ulimit - use the root crontabs and then su to the
user you need.

I first learned to use tricks like this when AT&T shipped a Sys V.2 for
their 3B that had a ulimit of 4000.   WITH NO WAY TO CHANGE IT!!!

Oh sure - root could up ulimit - but no one else.

The trick on that was to move /bin/login to /bin/login2, and then write
a short - typically under 10 lines - of c code called login that was
owned by root, that upped the ulimit to whatever you needed, and then
exec the /bin/login2 program to handle the logins.

That bit me quite badly one day when I accidentally left the leading /
from the file  /bin/login2  and I had forgotten to stay logged in on
another terminal.

System booted and no way to log in   :-(    -   Load the whole damn OS
and start over!

--

Even if I were playing sysadmin for a system with lots of users on it, I'd
still turn off the kernel configuration value, and use /etc/default/login
and other mechanisms to turn filesize limits on where appropriate.  USL
must have had a lawyer-turned-programmer on their staff to wire that sort
of thing into the kernel.

                -Ed Hall

init.c:
main(ac,av)
{
        ulimit(20000000);
        execv("/etc/init.real", av);

Quote:}

Of course, if something went wrong, you were *really* screwed... :-)

        /etc/conf/bin/idtune SFSZLIM 0x7fffffff
        /etc/conf/bin/idtune HFSZLIM 0x7fffffff
        /etc/conf/bin/idbuild
        init 6

Depending on which version of SVR4 your's is based on, the kernel will be
rebuild either when the idbuild is executed or when the init 6 is.

Quote:> Next, edit /etc/default/login and add (or change) the ULIMIT line:

>     ULIMIT=999999

> or some other suitably large value (in blocks).

-Israel Pinkas
--

        "Everybody's askaird of death, until it hits you ...
         then you don't care"              -Archie Bunker

: The trick on that was to move /bin/login to /bin/login2, and then write

I digress a little.  There used to be an optional file /etc/icode, that
ran before init, where you could raise the ulimit.

--
---

               ...pyramid!ctnews!tsmiti!dold

Cheers,
Guenther
--
Guenther Seybold, Siemens Nixdorf Informationssysteme AG, Mannheim.

--

Look in your System Administrator's Guide if you don't believe me:
on page B-30 it says in part: "The stune file can be edited to change
a value already placed there or to add an additional parameter that
you wish to set at a value other than its mtune default."

However, I'd agree that editing mtune directly is a Bad Idea.

Quote:> . . . .
>> Next, edit /etc/default/login and add (or change) the ULIMIT line:

>>         ULIMIT=999999

>> or some other suitably large value (in blocks).

>I recommend against that.  It is too easy to create super large files.  If
>you want larger files, ulimit <#blks> will bump the limit after the above
>is done will do the trick.

Perhaps setting a soft limit in /etc/profile (and the equivalent places
for other shells) is likely to be the best solution.  That way a naive
user isn't going to fill the entire disk with a "cat * >foo" command,
but other users aren't inconvenienced when they have to work with large
files.

Of course, all advice here is worth just what you paid for it.  Systems
differ in their users, usage, and requirements.  A filesize limit that is
appropriate for document preparation won't be appropriate for image
or audio processing, large databases, and so on.  I suppose we should
have suggested that, if large file handling is an uncommon occurance,
do it as root with "ulimit unlimited" and leave the system alone...

                -Ed Hall