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

[Theo de Raadt]

This is ridiculous.

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

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

> On Wed, Sep 12, 2001 at 01:34:52PM +0200, Markus Friedl wrote:
> > On Wed, Sep 12, 2001 at 12:30:08PM +0100, M.C. Vernon wrote:
> > > Using O_LARGEFILE is probably the least worst solution to this problem on
> > > Linux at least. 
> > 
> > i still don't see how a flag to open(2) can help if off_t is 32 bit?
> 
> Perhaps the idea was to make sure that only programs compiled with off_t
> being 64 bits could open large files.
> 
> Think, if an old program opened a large file and read sequencially past
> 2GB then tried to find the current offset then all hell would break
> loose -- thus the requirement that a new open flag or new open syscall
> be used might merely be meant prevent older programs from such
> situations.
> 
> Solaris, in fact, has an open64() and the headers take care of doing
> something like:
> 
> #define open open64
> 
> I bet that open64() internally sets O_LARGEFILE automatically so that
> OpenSSH should need no source changes other than defining some
> pre-processor constant to enable open64() et. al., on Solaris.
> 
> I can't say about Linux...
> 
> Nico
> --
> 
> Visit our website at http://www.ubswarburg.com
> 
> This message contains confidential information and is intended only 
> for the individual named.  If you are not the named addressee you 
> should not disseminate, distribute or copy this e-mail.  Please 
> notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system.
> 
> E-mail transmission cannot be guaranteed to be secure or error-free 
> as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses.  The sender therefore 
> does not accept liability for any errors or omissions in the contents 
> of this message which arise as a result of e-mail transmission.  If 
> verification is required please request a hard-copy version.  This 
> message is provided for informational purposes and should not be 
> construed as a solicitation or offer to buy or sell any securities or 
> related financial instruments.
>