On 9/17/05, Far=E9 <fahree@...> wrote:
> * One problem that SBCL has is that it tries to do all filesystem
> with BASE-STRING, which is only 7-bit when SB-UNICODE is defined.
> This sucks big stinky ass. I really think SBCL should provide 8-bit char=
> and 8-bit strings, be they BASE-CHAR or another CHAR type, unless it
> rehowls its filesystem code.
> =09touch "Far=E9" ; sbcl --eval '(write (directory "Far*")) (terpri)'
> It would also be mighty cool to have some magic to magically convert
> (simple-array (unsigned-byte 8) (*)) and (simple-array 8bit-char (*)).
Note that external-format or whatever support for namestrings won't do:
if the filename is not valid UTF-8 or whatever, you still won't be able
to access it. Inasmuch as the underlying filesystem interface is defined
in terms of octets, the only way to access it fully is in terms of octets.
(Of course, you make do with the latin1 subset of a 32-bit char being the
octet -- wasteful but works better than a 7-bit BASE-CHAR.) Personally,
I feel that not being able to fully access the filesystem is less than
useful. And if sb-posix is also using pathnames, so there's no escape
short of rewriting the whole interface. Sigh.
> * And, whoa, look how even a seemingly simple OPEN will do call directory=
> which itself will call truename! That's heavyweight stuff for a simple
> operation. And it makes my previous bug report about the brokenness of
> truename all the more pressing.
That's complete bullshit. I can't read properly. As Xophe told me, a simple
(trace directory) (open "/etc/motd") shows it doesn't.
> * I'm willing to fix the probe-file/truename problem, if no one else care=
> It involves doing a proper directory-truename before to do any path
> simplifications. [...]
Still holds. Basically, do the same as that realpath program used by c-l-c.
> * Finally, while hacking sbcl, I was bitten several times by the fact tha=
> SBCL begins writing a FASL immediately, and doesn't cleanup if it has to
> abort while detecting an error in the file.
Looks like it tries cleans up, but the cleanup is not sufficient if the
error badly messed with lisp, or the lisp is otherwise killed (and I
casually got segfaults while debugging that alien code).
Xophe, consulted on #lisp, for some reason, seems to dislike atomic file
replacement from a temporary; he argued about complexity or security
problems about it -- but I think his arguments do not apply to this case.
As concerns complexity, if even my cl-launch shell script can do atomic
file update (see its higher-order function create_file), there's no reason
why a lisp program can't do it. Here's the gist of it:
((s filename &optional (tmpname)) &body body)
`(evaluate-once (,filename ,tmpname)
(unless ,tmpname (setq ,tmpname (make-tmpname-for ,filename)))
(with-output-file (,s ,tmpname :direction :io
=09=09=09 :if-does-not-exist :create :if-exists :error)
(rename-file ,tmpname ,filename))
(ignore-errors (delete-file ,tmpname) nil)))
As for security, Xophe speaks of problems with /tmp -- but well, they
are problems with /tmp and atomic file updates works with a temporary
not in /tmp but in the same directory as where the fasl is to be created,
and this needs be owned by the user himself. There's no reason to ever do
anything directly in /tmp anyway: if you really want to do *anything*
interactively under /tmp, the only secure thing to do is to create a
directory /tmp/$USERNAME/ that you own (with a proper umask). Anything
else is a race condition that opens you to attacks.
Thus, mapping footruename.fasl to footruename.fasl-tmp seems plenty secure
enough to me -- and provides a nice network-aware interprocess locking=20
mechanism, too (with the correct NFS mounting options). If you want to be
paranoid, you should just check that the current directory is not
Even if we dont use atomic file creation, the least we could do is to not
tag a FASL as valid until it has been completely and successfully compiled.
The header should include a flag that is written last, or (if we don't want
to file-position) there should be a footer that includes a checksum,
Finally, I think no fasl should be created if there's an error. If there's
a warning, I'm not sure whether a fasl must be created, but if it must,
then loading it should be a warning, too.
[ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu=
Being a graduate student is like becoming all of the Seven Dwarves.
In the beginning you're Dopey and Bashful. In the middle, you are
usually sick (Sneezy), tired (Sleepy), and irritable (Grumpy). But
at the end, they call you Doc, and then you're Happy.
=09-- Ronald T. Azuma, http://www.cs.unc.edu/~azuma/hitch4.html