From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; SunOS 5.8 sun4u; Nav)

Description of problem:
tee does not open its outputfile with O_LARGEFILE.  It is the only command I
have seen that has this behavior.
The behavior can easily be verified with:
date | strace -eopen -f sh -c 'tee bytee > bysh'
The relevant output is:
[cut]
[pid 17444] open("bysh", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
[cut]
[pid 17444] open("bytee", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
The shell correctly opens the file with O_LARGEFILE.
Other utilities, such as uniq and sort not not have the bad behavior


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. date | strace -eopen -f sh 'tee bytee > bysh'
2.
3.
	

Actual Results:  strace shows the file created by tee is not opend with
O_LARGEFILE
Files opend by the shell *are* opened with O_LARGEFILE.  This the open file
cannot be larger than 2 GB

Expected Results:  The file should have been opened with O_LARGEFILE.  Files
created by tee should be able to grow beyond the 2G border

Additional info: