MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: FUP ate my db (and I did RTFM)

>>Yes, yes, I know, I'm doing all this. The reason why I want it as a single 
>>string is so that I can handle the *entire* pathname from within the db rather 
>>than splitting it up into parts. I think the reason why it's actually crashing 
>
>You have two options.  Store it has a two element list, then splice it in to
>the args to the file function, or accept it as a single string and then
>explode it. I guess my question is why are you trying to work around the system?

I've got a sysadmin's file management room, which provides a Unix-shell like 
interface. So all I'm getting from the user is a single string. I can't split 
it because there isn't an intelligent way to split it (besides, it's too much 
work). If /foo/bar is a directory, should that be ("/foo", "bar") or 
("/foo/bar", ".") or (".", "foo/bar")? And what about references to /? Anyway, 
this isn't the problem. Everything works fine.

>>is that while Unix systems will let you open a directory as a file, reads and 
>>writes don't do the obvious. I think the EOF marker is definately dodgy, which 
>>explains why fileread() appeared to just keep reading data until it ran out of 
>>memory.
>
>Reads and writes read and write bytes respectively.  They assume nothing
>about the underlying structure of the byte stream they are connected to.

Um -- you do know how Unix handles the EOF marker? It gets generated when you 
try to read past the end of the file. It's not a byte stored in the file. I 
don't know if directories generate it, which is why it'll keep reading.

>Attempting to place order into this is futile -- it's UNIX.  Admittedly,
>this is definately a bug in FUP allowing you to fileread directories, not
>much you can do about it besides fixing the code.

I might take a look and produce a patch some time. For now, testing in the db 
will do.

>>I know it's an `invalid indirection'... whatever that is. What does it mean?
>
>In terms of FUP or in terms of when that error is raised normally?

Normally.

>>Because I'm writing a generic FUP wrapper class, supposed to be proteected 
>>enough so that ordinary programmers use it, and there's no *telling* what 
>>they're going to do.
>
>So don't let them do just anything.  Check to make sure that a file exists
>using fileexists before calling file{read,write,append,delete,...}.  Use
>filelist to determine if it's a directory or a file and only them them do
>operations that are directory operations on directories and file operations
>on files.  If you want some semblence of security, don't just pass the
>arguments they pass you onto the builtins blindly.

That's exactly what I'm doing! The user API to FUP is going to be very 
limited. No subdirectories (each object gets its own directory), for example. 
Bit the bit I ran into problems with is the wizard section, which will let you 
do arbitrary file management.

(BTW, I got your message twice for some reason.)

--David

-- 
------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg --------------------
   If you're up against someone more intelligent than you are, do something
    totally insane and let him think himself to death.  --- Pyanfar Chanur
---------------- Sun-Earther David Daton Given of Lochcarron ------------------
References:
Home | Subject Index | Thread Index