Atrus has asked for the wisdom of the Perl Monks concerning the following question:

I'm working on a CGI script in a constrictive enviroment, one that won't let me write to files. So I decided to use the DATA meta-filehandle. The only problem is that it needs to completely overwrite the contents. How would I go about this? Can I open DATA for write (not append)?

Replies are listed 'Best First'.
Re: Emptying DATA
by chromatic (Archbishop) on Jan 05, 2002 at 12:51 UTC
    You can, if you use Inline::Files. As the pod says, though, if it whacks your source code, no one's responsible but you. If you can't write files, though, that probably won't help either.
Re: Emptying DATA
by Zaxo (Archbishop) on Jan 05, 2002 at 12:47 UTC

    Find a new environment. It is much more dangerous to overwrite the script. Are you sure you cannot write to files at all? If so, get your money back and find a host which gives you a real account.

    After Compline,
    Zaxo

      Find a new environment. It is much more dangerous to overwrite the script.

      I agree. If you're unable to get the "no writing files" restriction relaxed, find a different, less restrictive environment.

      If you're in some sort of "free" environment, calculate the amount of time you're going to have to spend to get around that environment's restrictions, then put a reasonable dollar value on an hour of your time, and multiply. Unless you place a low value on an hour of your time, free-but-restrictive can quickly become less of a good deal.

How about saving to RAM?
by metadoktor (Hermit) on Jan 05, 2002 at 19:36 UTC
    If you are working in a UNIX environment you may be able to make use of message queues. Message queues allow one application to talk to another using memory.

    Basically, what you would need to do is:

    1. Write a program that will create N message queues (with the appropriate permissions and uid/gid) equivalent to the number of files that you need. Also make sure that the program writes the message queue IDs to a file so that your CGI app can read them.

    2. Run the program once to create the message queues.

    3. Write your CGI application such that it reads the message queue ID(s) from disk and uses them to write/read to the message queue(s). Note: That you'll still have to come up with a way to lock a message queue to a particular CGI process otherwise you will have CGI processes that will be trying to use another process' message queue.

    4. Assuming that you have this setup correctly, you could have one CGI process write to a message queue and another or even the same CGI process read from that queue.

    In this fashion, you would be using message queues to act as files and not have to write to disk.

    The relevant perl functions that you would want to use are shmget, shmwrite, shmread and shmctl. You can read more about this on page 346 of the Camel book. Also the book recommends trying the IPC::SysV module from CPAN.

    There are, of course, limitations in using this type of shared memory in that, I believe, that once you pop the data off of the message queue that it is gone and unavailable for other processes to read. Sort of a write once, read once system.

    metadoktor

    "The doktor is in."

Re: Emptying DATA
by Atrus (Initiate) on Jan 07, 2002 at 08:02 UTC
    Thanks for the suggestions, the inline files plug was the most helpful. The major problem is lack of information about file/directory/etc. permissions, hopefully customer support will respond soon with something other than the unhelpful "you cannot modify files you don't have permission to modify"