Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#706 closed defect (fixed)

file-exists? does return #f on large files

Reported by: Christian Kellermann Owned by:
Priority: critical Milestone: 4.9.0
Component: core libraries Version: 4.7.x
Keywords: file-exists? 2GB large files Cc:
Estimated difficulty:

Description

Reported by Sven Hartrumpf

I have just lost some files (fortunately, they can be restored somehow)
because file-exists? returned #f for large files (> 2 GB).

Confirmed by Moritz for 32 bit chickens (on a 32 bit machine)

It does do the right thing on 64bit chickens

Change History (5)

comment:1 Changed 10 years ago by Christian Kellermann

(define (file-exists? name)

(##sys#check-string name 'file-exists?)
(##sys#pathname-resolution

name
(lambda (name)

(and (##sys#file-info (##sys#platform-fixup-pathname name)) name) )

#:exists?) )

(define (##sys#pathname-resolution name thunk . _)

(thunk (##sys#expand-home-path name)) )

What's that keyword for anyway? Also wouldn't a call to fstat alone suffice without even filling the stat structure?

comment:2 Changed 10 years ago by Christian Kellermann

On a 32 bit chicken fstat fails with
(gdb) p perror()
file-exists: Value too large for defined data type

comment:3 Changed 10 years ago by Christian Kellermann

Which results from

EOVERFLOW

(stat()) path refers to a file whose size cannot be represented in the type off_t. This can occur when an application com‐
piled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds (2<<31)-1 bits.

of course

comment:4 Changed 10 years ago by felix winkelmann

Resolution: fixed
Status: newclosed

This should work now . In the current masterversion, file-exists? will signal an error on any other error condition but ENOENT.

comment:5 Changed 9 years ago by felix winkelmann

Milestone: 4.8.04.9.0

Milestone 4.8.0 deleted

Note: See TracTickets for help on using tickets.