> I cannot _test_ whether the file has zero size. Except by parsing the
> output of (run (ls)) or something like that...
>
> > At least on the system I'm on, rather than doing
> > something semi-rational like throwing a scheme level error,
>
> (which it does for me:
>
> Error: 75
> "Value too large for defined data type"
> #{Procedure 13546 (stat-file in scsh-level-0)}
> "large_file"
> #t
> )
That's very catchable if I'm reading it correctly. That's the
correct number and text to be EOVERFLOW on linux. You won't be able
to tell how large the large file is, but you can tell that it's large.
As a guess, your ability to do this is specifically dependant on
off_t being a 32 bit quantity, and the kernel knowing that you're
using a version of stat that is only capable of representing 32 bit
sizes. This would explain why I see the wrong thing where you see the
right thing. scsh is expressly using an FFI function that deals in
longs, which will do the wrong thing on a system where off_t is
inherently 64 bits.
> But also
>
> (file-exists? "large_file")
stat is the pretty much the standard method to determine if a file
really exists. Reading a directory doesn't account for the case of a
broken symlink. The file will "exist" as far as the directory entry
is concerned, but isn't backed by anything real. There are probably
other cases, but this one leaps to mind.
|