Kbase P143611: Binary dump as userid root for table exceeding 2Gig results in exceed maximum size on file table.bd
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
3/26/2009 |
|
Status: Unverified
SYMPTOM(s):
Binary dump as userid root
Binary dump for table exceeding 2GB results in exceed maximum size on file table.bd (9452)
SYSTEM ERROR: Attempted to exceed maximum size on file <pname>. (9452)
** UNIX maximum file size exceeded. <program>. (303)
Binary dump of file larger than 2 Gig
largefilesupport not enabled
ulimit -f = default (2097151 x 512k ~ 1 GB)
The binary dump should create multiple .bd files when the binary dump is larger than 2GB when large file support is not enabled.
binary load fails with error 2257
Unable to open or create scthist.bd, error 27. (2257)
FACT(s) (Environment):
Caldera Open UNIX/SCO UnixWare
Linux Intel
Progress 9.1C
Progress 9.1D
Progress 9.1E
CAUSE:
A new feature was implemented in the Version 9.1C Enterprise Database product to enable database extents to be larger than 2GB. This feature is not supported on UnixWare or Linux OS because Progress still supports earlier versions of these OS that don't accommodate large files.
The binary dump should create multiple .bd files when the table being binary dumped exceeds 2 Gig and large file support is not enabled, as it should not be for these OS.
Testing showed that no matter what the ulimit set for root, 'attempt to exceed maximum size of file table.bd' resulted. When dumping as non-root userid, then the table.bd split (as expected) into .bd1 .bd2 etc according to the value that ulimit -f was set to.
FIX:
If the owner of the executable is root and the setuid bit is set, it will still run as root, i.e. rwsrwxrwx root _proutil. You can do one of two things:
1. Remove the setuid bit with chmod.
2. Change the owner of the executable with chown.