[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Can't read directory: Value too large for defined data type

From: Steve Kirstukas <sjk60_at_iastate.edu>
Date: 2004-06-01 23:22:47 CEST

Problem is resolved. Thanks to those that offered some tips. We are using an
IRIX file server and the issue involved cookie length. Problem was fixed by our
sysadmin specifying 32 bit option.

from:

http://64.233.167.104/search?q=cache:66HN0Fe8waoJ:www.geocrawler.com/archives/3/789/2001/9/100/6531172/+%22Value+too+large+for+defined+data+type%22+irix&hl=en

////////////////////////////////
In 2.4.9 Linus opened for 64-bit readdir cookies (before all cookies
were truncated to 32 bits). That means that *if* the IRIX server is
returning cookies that are 64-bits long, and *if* your programs are
not using the 64-bit version of readdir, then glibc will return
EOVERFLOW.
This is because glibc internally calls the getdents64 system call, and
assumes that the results will always be 32-bit compatible unless the
directory is large. Don't ask me why they thought they could assume
this, but they do...

You can try to use the 32bitclients options on the IRIX machine
(although I'm not sure that causes them to actually send out 32-bit
cookies). Alternatively, if you are able to upgrade it, the newer IRIX
kernels seem to use a more sane scheme for their readdir offsets.

////////////////////////////////

> On Thu, May 27, 2004 at 11:20:02PM +0100, Philip Martin wrote:
> > "Steve Kirstukas" <sjk60@iastate.edu> writes:
> >
> > > svn: Can't read directory 'VE_Xplorer': Value too large for defined data
type
> >
> > Google suggests that this is problem with largefile support, if you
> > use strace I suspect you will see a stat() call fail with the error
> > EOVERFLOW. Anyone care to summarise the state of largefile support in
> > Subversion/APR?
>
> APR HEAD has large file support out-of-the-box on platforms with a
> 32-bit off_t, so Subversion should "just work" there. APR 0.9 can be
> rebuilt with LFS support using -D_FILE_OFFSET_BITS=64 etc but that's not
> really a supported configuration since it changes the library ABI and is
> generally a good way to shoot yourself in the foot if you're not
> careful.
>
> The APR 0.9 branch has some "large file features": the APR_LARGEFILE
> flag to apr_file_open(), which lets you open and write/read >2gb files,
> but you still can't stat them (useful for log files). Also I made
> apr_file_copy() work with >2gb files on Linux at least (despite my
> ardent protestation that that wasn't an APR problem :), so that should
> make the svnadmin hotcopy issue go away.
>
> joe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jun 1 23:23:32 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.