Hi, A bug I've had reported is that scp doesn't work with large files (Debian bug number 106809). The problem seems to be scp.c:504: if ((fd = open(name, O_RDONLY, 0)) < 0) Is there some reason why making that if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) would break things? It seems a simple fix to me... Thanks, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
On Mon, Sep 10, 2001 at 12:33:18PM +0100, Matthew Vernon wrote:> Hi, > > A bug I've had reported is that scp doesn't work with large files > (Debian bug number 106809). The problem seems to be scp.c:504: > > if ((fd = open(name, O_RDONLY, 0)) < 0) > > Is there some reason why making that > if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0)#ifdef O_LARGEFILE if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) #endif would perhaps fit better. E.g. Cygwin has no O_LARGEFILE. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com
why is O_LARGEFILE needed? is this some standard API? On Mon, Sep 10, 2001 at 12:33:18PM +0100, Matthew Vernon wrote:> Hi, > > A bug I've had reported is that scp doesn't work with large files > (Debian bug number 106809). The problem seems to be scp.c:504: > > if ((fd = open(name, O_RDONLY, 0)) < 0) > > Is there some reason why making that > if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) > > would break things? It seems a simple fix to me... > > Thanks, > > Matthew > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org
>On Wed, Sep 12, 2001 at 12:30:08PM +0100, M.C. Vernon wrote: >> On Wed, 12 Sep 2001, Theo de Raadt wrote: >> >> > O_LARGEFILE is an API that should never have showed up. >> > >> > It is ridiculous twisted bullshit. Those vendors were foolish. >> >> OTOH, it has showed up. On AIX, HPUX, Solaris and Linux. BSD and Tru64 >> don't have it. Furthermore, using this flag on platforms that support it >> should have no bad effects (assuming proper error checking). >> >> 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?Please don't bring Solaris into the justification for passing O_LARGEFILE to open this is NOT the recommened way to do it. On Solaris if you are building a 64bit application off_t is 64bit and open(2) and friends automatically deal with largefiles correctly. If you are a 32bit application you have a choice but passing O_LARGEFILE to open is NOT one of them. For more details see lfcompile(5) http://docs.sun.com:80/ab2/@LegacyPageView?toc=SUNWab_40_4%3A%2Fsafedir%2Fspac e3%2Fcoll3%2FSUNWaman%2Ftoc%2FREFMAN5%3A0059_lfcompile.5;bt=man+Pages(5)%3A+He aders,+Tables+and+Macros;ps=ps%2FSUNWab_40_4%2FREFMAN5%2F0059_lfcompile.5&Ab2L ang=C&Ab2Enc=iso-8859-1 -- Darren J 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