delete files from a directory and db using php, mysql and crontab

Is there something wrong with the linked files?

... wrong like you can't reach them or wrong like they don't work?

They are heretofor untested. For the most part, I'm looking for confirmation that I am doing it right, that there ISN'T a simpler way, or any glaring errors. I'm not sure how to test the older file deletion, or if this is even the right way to go about it.

The crontab I'm happy to report, works fine, lol. I got a lovely error message last night that it couldn't find expiredfiles.php (I don't have it in a place where it can work until I'm sure how I'm going to go about it), so that much is right.

While talking to the client, what I really need to do is delete files by file-name for that date.

Further discussion, and I've run into a bit of a mental block -- notably, when a client is deleted from the db, I need to delete all the files in the directory associated with that client.

Otherwise, the rest of the script should work as intended.

I don't want to just hope they don't lose clients, so if you wouldn't mind taking a look at the script again, would someone be able to unravel the knot I've put in there?

I'm having a hard time because I don't know what your db looks like or your directory structure.

And why are you doing this:
foreach ($email_rst['id'] AS $ID) {

Ah, okay.

DB - two tables, one for files, the other for users.

files contains: file_id, id, file_name, file_size, file_description

users contains: id, firstname, lastname, company, email, username, password

one directory for all the client files, each file is named "client" . $id . "_" . $filename

Pretty simple, right? Nothing unexpected in there?

I was thinking with the foreach to loop through each id that belongs to a client, to check to see if that id exists... oh, I see what you're saying.

So help me here, I have files named clientID_file_name, where ID is the id of the client and file_name is the rest of the filename, including the extension. When a client is deleted, s/he's removed from the db, but the files aren't eliminated from the directory.

Perhaps that's the right place to do it, then, while I have a valid ID and I don't need to check an array...

Sorry for the confusion! Clearly it's because I hadn't thought it all the way through.

SO! Then my question is how do I delete a file from a directory, *knowing its name* (since I can make an array of all files for that id before I delete it, right? Right out of the db).

Wow, that's a lot simpler question. Anyone have the answer?

woooaah... complicated stuff... thats way beyond me.

Our developers here have written an automated system that deletes customers hosting accounts after a certain time if payment hasnt been received, however everything is intricatly linked, I think we use the domain name as a reference as every service we sell has to have a domain name associated with it... Your files need to have a unique ID that can be linked up to a record in the DB. I'm sure that would make things simpler.

Thanks, Andy -- they do. $file_name is unique. If you upload the same file to the same client, they are named in successive order -- i.e. client28_thisfile.jpg, client28_thisfile01.jpg, client28_thisfile02.jpg. All the files are in the same directory per client request, which is part of the problem. If I had separate directories for each client, I could just delete the directory when the client was deleted.

The expired files should delete fine, it's just the files attached to expired CLIENTS that are a bit confusing to me at the moment, but I think once I know for sure what function will delete files from a directory (unlink works?) then I will be able to have those files deleted when I delete the client.

I think.

basically i think for each expired customer you need to loop through every file in the directory and delete those that contain the customer id in their file name... so a loop inside a loop kinda thing should do it.

the function you need is delete a file is

to match the customer id in the file name you need to do

so to delete a file that matches you do:

I hope thats some help... I hope i havent misunderstood what your trying to do...

That is helpful, thanks. Unlink seems so innocent, when really it's a killer.

not tested, but should help with the theory...

Oh, brilliant, yes, of course we don't want to email people for stuff that we're going to delete now.

Thanks, Mark, Andy, for unravelling my knot, I'll apply this and test it and link to the final solution for other people to make use of, if needed.

http://www.zerocattle.com/examples/expiredfiles.phps

That's my final solution and it works exactly as intended to work. What I decided to do about the expired client is to delete all associated files, then delete the client, not rely on the daily script to find stuff.

Many thanks, and I hope other people find it useful.

HOWEVER, because of the problem running PHP from crontab (use lynx, wget, or have PHP running as CGI), I'm going to probably rewrite it in Perl. Or, rather, I'm going to hope Wil says I only need to change a couple of lines, lol.

There's a problem running PHP from crontab?

Perl would be your best alternative. Could write a shell script, but you need interaction with a database.

Yeah, if PHP is an Apache Module, you can't run it from crontab unless you use wget (which has to be available) or install Lynx and run it from the crontab.

The main problem is I need it to be very portable, to fit on many different server configurations, so I can't guarantee I'll have PHP as CGI, or have wget, and I pale at the idea of installing Lynx.

Well, every box that I've had access to has had both wget and lynx.

Either you're really lucky or I'm doing something really wrong. How do you tell if you have those things? I assumed I didn't because the crontab didn't work.

/bin/sh: /usr/local/lib/php/bin/php: No such file or directory and again, not working. :\

The include_path may not show the correct path to php. Check phpinfo() again and see if there is a --prefix in the "configure command"

Does that tell you waht you need to know? What *I* need to know? lol.

There is no --prefix, so the default (/usr/local/php) would have been used.

So try:
/usr/local/php/bin/php -f /path/to/script.php

Or... better yet, try this in the shell first:
/usr/local/php/bin/php -r 'echo "found php!\n";'

I don't have shell access on my own server, and it's not working there. I'll try it on the client server and see if I can find it.

I'm getting very frustrated now, so I think maybe rewriting it in Perl would be easier. I say this BEFORE rewriting it, naturally.

You can fake shell access:

okay, that didn't have any results, though it was really really cool to learn.

I went digging and found that my host uses MindTerm (java applet) to fake SSH, so I used that.

This is what it returned for a "whereis php"

So, now, which do you suppose is what I need?

I tried them all in the passthru above, to no avail.

Aha, okay, I have access to the server through shell. Of course, now I can't remember what the heck I needed to do this for. *argh* This over-a-few-days troubleshoooting is ridiculously hard.

Whee, exploring again, found lynx. Woo!

Okay, so I have lynx, and I have php somewhere I don't know how to find it. How do I use wget? I want to cover all my bases here.

Update: it WORKS! Finally. *phew* Using lynx is solid, does the job.

For wget, you basically just use: "wget URL"

There are quite a few options if you do "wget --help". Including no-cache, faking the User-Agent header, and faking the Referer header.

As for php, my guess is that /usr/bin/php is the binary.

okay, I'll check it out. Thanks, Mark.