Erik Naggum wrote:

> * Andrew Begel
> | I'm using some software that called excl::filesys-filestat.  In ACL 4.2,
> | this took one argument (the pathname), but ACL 4.3 is telling me that it
> | takes 2 or three args now.  Does someone know what the other args should
> | be?  There's no documentation for this function.
>
> (excl:arglist #'excl::filesys-filestat)
> => (excl::name excl::filestat &optional excl::linksp)
>      t
>
>   it is unclear to me what `filestat' is supposed to be, but the following
>   call does not cause an error and fills the vector with useful values:

I think excl::filesys-filestat corresponds to the Unix stat function, so my guess is the
filestat argument is a stat structure and the optional linksp argument specifies the
behavior when the named file is a link. Since this is an internal function, you may be
better off replacing it with your own foreign function interface to stat.

>
>
> (excl::filesys-filestat "/home/erik/.X-error.119"
>                         (make-array 10 :element-type '(unsigned-byte 32)))
> => #(0                  ; not filled in, presumably a struct identifier or something
>      3061065815         ; no meaning found (see note)
>      3093381980         ; modification time in universal time
>      31583279           ; access time (see note)
>      420                ; #o644, the permissions bits
>      646                ; the UID of the file
>      10                 ; the GID of the file
>      0                  ; a file type flag.  known types:
>                         ; 0 = file
>                         ; 1 = directory
>                         ; 3 = symbolic link (only if linksp is non-nil)
>                         ; 4 = FIFO special
>                         ; 5 = Unix socket
>                         ; 6 = character device
>                         ; 7 = block device
>      11330              ; inode number
>      1800)              ; bits 15..8 = 7 = major device (a scsi disk here)
>                         ; bits  7..0 = 8 = minor device (disk 1, partition 0)
>
>   there is a constant 3061065600 in the code vector of this function that
>   appears to be the universal time representation of 1997-01-01 00:00:00,
>   and there is a curious offset from this number in slot 1.  slot 3 appears
>   to be the access time of the file relative to this time.
>
>   the first argument (name) must be a simple-string or a fixnum, and the
>   fixnum seems to represent a C string in memory, like the char * returned
>   from FFI functions.
>
>   it would be nice if somebody from Franz could corroborate my story, which
>   is based on disassembly, empirical tests, and hunches.
>
> #:Erik



--
Phil Chu            http://www.cinenet.net/~pchu
Digital Chameleon   http://www.digitalchameleon.com/