scp doesn't work with large (>2GB) files

[Darren Moffat]

>This is ridiculous.
>
>It means that any existing program that is not aware of this flag
>will have two divergent behaviours.

It is not a flag in the recommened way to deal with it. It is a differnet
ABI that is enabled at compile time to change the off set size and the
API calls that use it.

Part of the reason it was done this way is to help transition from the
old 32bit off_t to a 64bit off_t and to provide access to largefiles
from 32bit applications.

A program either is 64bit safe or it isn't it isn't possible to
have two divergent behaviours.  It is possible to generate 2 different
binaries from the same source one that works with largefiles and one that
doesn't depending on your compiler flags when building a 32bit binary.
When building a 64bit binary there is only one option and that is a 64bit
off_t.

It isn't just a matter of recompiling your code either, you must also
check all of the code to ensure that you correcly use off_t everywhere
rather than sloppy code that uses int or long for file offsets (there is
some code in scp that has/had incorrect types for file offsets).

>That is the kind of bug that results in security holes.  I have tons
>of experience with this, and this is INCREDIBLY dangerous.

Solaris has had this functionality in a released version of the OS since 2.6
(1997) and we have had no indication that is it possible to cause any
security issues because of it.

Some people have been recommending the wrong way to deal with this
issue but there is a standard interface and it does work as designed
when properly called and to my knowledge there are no security issues
with it.  

Passing O_LARGEFILE to open(2) without any other changes is the wrong
way to do it and may cause problems with code that doesn't check all
return values for functions that manipulate files and file offsets.

I believe the Solaris man pages largefile(5), lfcompile(5) on docs.sun.com
are a good starting point for 

--
Darren J Moffat