#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 13 years ago by
comment:2 Changed 13 years ago by
On a 32 bit chicken fstat fails with
(gdb) p perror()
file-exists: Value too large for defined data type
comment:3 Changed 13 years ago by
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 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
This should work now . In the current master
version, file-exists?
will signal an error on any other error condition but ENOENT
.
(define (file-exists? name)
(define (##sys#pathname-resolution name thunk . _)
What's that keyword for anyway? Also wouldn't a call to fstat alone suffice without even filling the stat structure?