file-exists? confused

file-exists? confused

[Bill Schottstaedt]

The new Guile's file-exists? function is confused by very large files:

guile> (version)
"1.8.0"
guile> (file-exists? "/home/bil/zap/sounds/bigger.snd")
#f
guile> (quit)

/home/bil/ ls -la /home/bil/zap/sounds/bigger.snd
-rw-r--r--  1 bil bil 6350320648 Mar 13 04:07 /home/bil/zap/sounds/bigger.snd

guile> (version)
"1.6.4"
guile> (file-exists? "/home/bil/zap/sounds/bigger.snd")
#t



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: file-exists? confused

[Kevin Ryde]

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:
>
> The new Guile's file-exists? function is confused by very large files:

Ahh.  I changed it from access() to stat() to get the perms right
under setuid.  I think you'll find you can't open such a file in
guile, so saying it doesn't exist is bad, but not terrible.

I guess we should compile with _FILE_OFFSET_BITS == 64 and make sure
uses of off_t can cope with being either 32 or 64 bits.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: file-exists? confused

[Kevin Ryde]

Actually, I see off_t is exposed through the ptob port descriptor
funcs, so implicitly changing to off64_t would break applications.

It'd be nice if guile could use the 64 functions internally.  There
might need to be new entries in the ptob for seek64 and truncate64
versions of the seek and truncate funcs.  Or a flag saying which
flavour is in use.

There doesn't seem to be any room in that struct, but if it's always
created by scm_make_port_type then perhaps adding new fields to the
end would keep compatibility.

One thing that could be done straight away though is use stat64 and
readdir64_r for all the guile internal bits.  That'd give information,
even if you can't actually read/write large files.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: file-exists? confused

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Actually, I see off_t is exposed through the ptob port descriptor
> funcs, so implicitly changing to off64_t would break applications.

I think we need to redo the public port API anyway, for Unicode and to
clean it up.  At that time, we can also get large files right.
 
> It'd be nice if guile could use the 64 functions internally.  There
> might need to be new entries in the ptob for seek64 and truncate64
> versions of the seek and truncate funcs.  Or a flag saying which
> flavour is in use.
> 
> There doesn't seem to be any room in that struct, but if it's always
> created by scm_make_port_type then perhaps adding new fields to the
> end would keep compatibility.

Yes, that is good enough.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: file-exists? confused

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
>> There doesn't seem to be any room in that struct, but if it's always
>> created by scm_make_port_type then perhaps adding new fields to the
>> end would keep compatibility.
>
> Yes, that is good enough.

I might do something for stat and readdir first, then that struct.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel