TweezerMan

Welcome to the forums, Nick!

I'm with Bob - I think the odds of you having a boot virus or a problem with the MBR is very slim. Digging around on the WD site, I found this post: "Why do I encounter errors or data corruption in Windows 98/ME?" The page list two possible causes: 1) The BIOS is allowing the drive to send/receive data faster than the chipset on the motherboard can handle, or 2) problems with the IDE cable connected to the drive. For problem #1, they recommend going into the computer's BIOS Setup and disabling UDMA (Ultra-DMA) and setting the drive to use Mode-2 instead. For problem #2, they recommend replacing the IDE cable. The boot diskette you made should have an installed an 'overlay driver', which should load every time the computer is booted. I don't know if you see any message referring to 'EZ-BIOS' or something like that when the computer is booted up - that would be the drive overlay loading. It's possible that the drive overlay isn't working correctly, but I'd try changing the BIOS option noted above, and trying a different IDE cable if you have one. This will be time consuming - you'll have to re-format the drive and re-install Windows to test and see if either option fixes your problem. ***** Going back to your earlier post: You were hitting the 64GB limitation of the fdisk and format programs that ship with Windows 98. There is a replacement for fdisk at the MSKB web site, if you need to use fdisk to partition a disk larger than 64GB. I don't know if you were trying to use Win98's fdisk, or relying on the WD tools exclusively for partitioning and formatting. I'd recommend using the WD tools exclusively to partition your drive to avoid issues like this. In the detailed product specs, a WD 120GB disk is listed with: One sector holds 512 bytes of data, so the true capacity of the drive is: >234,441,648 sectors X 512 bytes/sector = 120,034,123,776 bytes Most people would see that number and agree that it is 120GB. This assumes that 1GB = 1,000 X 1,000 X 1000 bytes. The computer sees it a little differently: 1 KB = 1,024 bytes; 1 MB = 1,024 KB; 1 GB = 1,024 MB. The above size, converted to MB, where 1 MB = 1,024 X 1,024 bytes: >120,034,123,776 bytes / 1,024 / 1,024 = 114,473.46 MB The 64GB limit of fdisk in MB = 64 GB X 1,024 = 65,536 MB. Subtracting the 64GB fdisk limit from the hard drive capacity: >114,473.46 MB - 65,536 MB = 48,937.46 MB reported capacity by fdisk. Looks pretty close to me - close enough that it explains the behavior you were seeing. Even if you had the replacement fdisk.exe from MS though, it would not have helped unless the computer's BIOS could properly handle a hard drive of that size (I seriously doubt it could).

Welcome to the forums, Erick!

Welcome to the forums, Tom! I'm aware of only one script that allows automatic creation of e-mail accounts, and it is banned on TCH servers. As others have mentioned, the ability to automatically create e-mail accounts is something that is very prone to abuse.

Welcome to the forums, vicgray!

Welcome to the forums, cs323232!

Welcome to the forums, Rich!

Glad you were able to get it all straightened out! I'm sorry the fixfiles.php script isn't working for you. Without knowing what the error messages were, I don't have any idea what could have been wrong.

Once you've created an album, I don't know that changing the album name would change the directory name on the server. Wiping out the album and recreating it does sound like your best bet to me.

The apostrophe (single quote) in "Gail's" is breaking the query. The query is trying to pass a string (text) that starts with a quote: ...and MySQL is seeing the quote in "Gail's" as the end of the string. The text following that apostrophe is causing the error, since it's not valid SQL. The problem appears to stem from the directory name on your server containing an apostrophe, but honestly I'm not sure how you would fix that without breaking your album. I have a Coppermine install with album names that do contain apostrophes, but the directory names on the server do not. Hope this helps...

Glad to hear it's finally working!

The image in your BeatForce article is using a secure URL as the image src URL: ><a href="http://www.beatforce.org/"><img src="https://developer.berlios.de/dbimage.php?id=391" align=left height=32% width=32% hspace=20></a> (Note the 'https://' in the img src URL.) It appears that all you need to do is change the 'https://' to 'http://', and you should no longer receive the security certificate notices.

Your cron job needs to specify the local directory path to runcron.php, not the URL: >/home/cpanelName/public_html/admin/runcron.php > /dev/null If there was no PHP binary on the server, you would receive an error message along the lines of 'Bad interpreter'. There is a PHP binary on your server. Well, maybe. The runcron.php script isn't really set up so you can browse to it, but whether you see anything else would depend on whether your expire.php script actually output anything.

In this instance, no, it does not matter whether you use single or double quotes to surround the URL. Try changing the first line of the runcron.php script to the following: >#!/usr/bin/php That should be '> /dev/null' - 2 L's in 'null'. Permissions on expire.php should be fine as long as they're at least 0644.

Actually, in your case, the runcron.php file should look like this: >#!/usr/local/bin/php <?php include('http://www.my-TCH-site.com/admin/expire.php'); ?> The URL to the script you were originally trying to run with lynx is what needs to go in the include line. I'd probably use #!/usr/bin/php in the first line of the script, but either one should work. It specifies the location of the interpreter that will be loaded first (in this case, the PHP binary), which will then read and run your script. When a cron job starts, it starts as just a normal shell. It has no idea what language your script is in - PHP, Perl, Ruby, Python, etc. The first line is the path to a program that can read, understand, and execute your script.

Basically, no. PHP is installed on TCH servers as both an Apache module (what most users deal with and what your developer is thinking of) *and* as a CGI/CLI binary. If the script does not work because there is no PHP CGI/CLI binary on your server, this would be an issue you should have the Help Desk correct.

Welcome to the forums, r32chaos!

You should be able to go to 'Webmail' in your CPanel, log into either Horde or SquirrelMail, and delete your e-mails from there.

Welcome to the forums, DeyaEddin!

The way I understand it, generally, no, you would not be able to do this. As you noted in your post, your account would not be able to access directories in your customers' accounts to create the necessary files, and you would not have the necessary root access to chown() the user files so your customer owns them after you create them. I believe you would indeed need to have a dedicated server in order to do what you're asking. On the page you linked to, this is the option described under 'G2 Hosting for Friends'. I'm not sure this issue is avoidable. It's not much different from the multiple copies of phpBB, IPB, Movable Type, WordPress, Coppermine, etc., that are installed on TCH's servers. It's the only option you have, other than installing a separate copy for each customer. But this method has its drawbacks as well - your customers' URLs to Gallery would be pointing at a subdomain of yours, rather than at their own domain. I'm not sure I'd be happy with that particular solution.

One way you could do it is with an iframe. In the table cell where you want the browser window to be displayed, you could use code like this: ><td width="320" height="240"><iframe name="frame1" width="320" height="240"></iframe></td> To have a link open in this iframe window, the link needs to have a 'target' attribute that matches the iframe's 'name' attribute: ><a href="http://my-TCH-site.com/" target="frame1">Click Me!!</a> Clicking the above link would cause the linked page to be opened in the iframe in your table.

If the script runs fine when called in a browser, but has errors when run directly from the command line (cron job), it's a pretty safe bet that the script code has something in it that isn't correctly handling the different environment it's running in.

The script indeed did not run properly. The line number and file name in the error messages indicate where in the code you should start looking for the cause of the error. Before investing a lot of effort into trying to debug those errors, you might want to take a look at and try out a suggestion TCH-MikeJ made in another related thread.

I don't think setting it to run every minute is necessary. When I'm testing a script with a cron job, I set the cron job to run hourly, and when I'm ready to test it, set it to run 5 minutes or 10 minutes from now (taking the minutes from the current time, add 5 or 10 minutes, then set the cron job to run every hour at that minute). If I want to test again sooner than an hour, I just set the minutes portion of the cron job again.

Another example that might require a modification to a script: A difference in behavior between environments. When a script is called up in a browser, the web server automatically changes the 'current working directory' to the the directory where you script is located. This allows relative includes to work (such as './includes/myscript.php'). When a script is called in a cron job with 'php -q', neither cron nor PHP change the 'current working directory'. The initial current working directory for a cron job is your home directory - '/home/cpanelName'. A script with a relative include path would fail to find the file. To correct for this, the PHP script would need to be modified to 1) immediately perform a chdir(); at the beginning of the script to change the current working directory, or 2) use absolute file paths when specifying file and directory names. (#1 is usually an easier modification to perform.)