TweezerMan

Assuming that there's really one file with a problem, you could do what's known as a 'binary search' to figure out which file it is. Take your zip file with 100 jpgs in it, split it into 2 zip files with 50 jpgs each, and try to mail those to yourself. One should be successfully sent, one should fail. Take the 50 jpg zip file that failed, split it into 2 zip files with 25 jpgs each, and try to mail those to yourself. Again, one should be successfully sent, and one should fail. Take the 25 jpg zip file that failed, split it into 2 zip files, one with 13 jpg files and the other with 12 jpg files in it, and mail those to yourself. Again, one will be sent, and one should fail. Keep repeating this process until you are down to mailing two zip files with one jpg in it each - the one that fails will contain your problem file. Number of e-mails required to identify the problem jpg file: 14. It's still quite a few, but better than zipping each one of them individually its own zip file then mailing 100 e-mails to yourself. During this process, if both e-mails for a particular step are both successfully sent, then the problem isn't with the jpg files - it's something odd about how they've been assembled in the large zip file. Side question: I noticed on the gmail sire that e-mail attachments are limited in size to 10MB. Factoring in e-mail headers and overhead, the effective real size of an attachment that can be sent can be somewhere between 6 and 10MB. How large is the zip file containing your 100 jpgs?

Welcome to the forums, TubeHead!

This is probably a long shot, but you may want to scan the jpg's in that zip file with a virus scanner. There's an exploit (on Windows PCs, from what I remember) where malicious code inside of specially crafted jpg's could be executed. Assuming one or more of the pics had been infected, gmail could be picking up on that virus code.

Welcome to the forums, dahowlett! Serpentine is correct - it is not possible to change how CPanel sets up usernames and database names. Yes, it is. While it is possible to install MT directly into the public_html folder, I do not recommend it as then the MT application files get mixed together with your weblog pages in the same directory. Also, MT 3.16 currently has a bug that prevents it from setting login cookies properly if MT is installed to the public_html directory (root directory of domain). Usually this is due to the StaticWebPath setting in mt.cfg not being set correctly. If you followed the instructions on the TCH help web site, you do not need to uncomment or set StaticWebPath. The 404 errors would most likely be due to the CGIPath setting in mt.cfg not being set correctly. Linux path and file names are case sensitive - the URL you indicated above (www.domain.com/MT/mt.cgi) should be www.domain.com/mt/mt.cgi, as you installed MT into the public_html/mt directory. I tried looking at your mt.cgi and mt-check.cgi files - I'm receiving 404 errors with the following message: It appears that you tried to enable MT's dynamic publishing feature, but something is not configured correctly. The .htaccess file in your public_html directory (or possibly in your public_html/mt directory) has special directives in it that make dynamic publishing work, but they're pointing at the wrong directory. mt-view.php should be created by MT in the public_html directory, not the public_html/mt directory. I suspect that the settings in Weblog Config (Local Archive Path, Site URL, Local Archive Path, Archive URL) were not configured correctly prior to enabling dynamic publishing. It looks like you have a number of problems, but nothing that's impossible to solve - they just need to taken one at a time.

Welcome to the TCH family and forums, coloradoairphoto!

Welcome to the forums, Chris!

Option 1 look possible, but I don't see how you could implement option 2 using just iptables firewall rules - the firewall would not be aware of the username, nor whether they had an active SSH session or not. Assuming you have IP masquearading (NAT) configured correctly in your firewall, I believe you could use rules like the following: >iptables -t nat -A PREROUTING -i eth0 -p tcp -s {IPmask1/Subnet1} --dport 3389 -j DNAT --to 192.168.2.11:3389 iptables -t nat -A PREROUTING -i eth0 -p tcp -s {IPmask2/Subnet2} --dport 3389 -j DNAT --to 192.168.2.11:3389 Normally, you'd have a default action of DENY in your ruleset, so that should deny connections from other IP addresses. It's been a long time since I've messed around with Linux and iptables. I don't have a box to test the above on and my iptables knowledge is very rusty, so I don't know if the above is correct or if I'm missing anything. You might search Google and see if there's anything there that could help you as well. Since you are new to Linux and iptables, I'd highly recommend that you install and use an iptables firewall application (a couple I know of are Firestarter and Guarddog), so you don't inadvertantly leave your machine wide open while you're learning iptables. Hope this helps...

I've never used it, but I did a little searching on the net and I believe I know what your problem is. >xmlhttp.open("GET", url, true); The third parameter ('true' in this case) specifies whether the request is made synchronously (false) or asynchronously (true). Asynchronous requests are done "in the background" and execution of your script continues while the request is processing. Your window.location.reload(); will execute unless the page request finishes before the script gets to that line. You need to either wait for the asynchronous open command to finish before reloading your page, or you need to execute a synchronous open command, which will halt code execution until the page load completes (but may make the browser appear to be hung, depending on how long the page request takes). Asynchronous open - Using event to trigger window reload when page request is complete: >xmlhttp.open("GET", url, true); xmlhttp.onreadystatechange = handleResponse; xmlhttp.send(null); // Script execution continues... function handleResponse() { if ( xmlhttp.readyState == 4 ) { window.location.reload(); } } Synchronous open - Script execution stops until page request is complete: >xmlhttp.open("GET", url, false); xmlhttp.send(null); window.location.reload(); Hope this helps...

Depending on the CMS you're using, the settings may be stored in a database that would also need to be reset if you wanted to start over from scratch.

Welcome to the forums, speedy_julez! There's many sites on the internet with tutorials and information to help you learn HTML (and CSS). You could start off with the W3Schools HTML Tututorial.

Welcome to the forums, Ron! I'd second the recommendation for a font manager - no one needs 5000 fonts loaded up at the same time, all the time. As far as I know, Windows XP does not impose any arbitrary limits on the number of fonts installed. I don't know if Photoshop CS has any limits, but the symptoms you're describing don't sound like a font limit problem to me. I suspect that one or more of those 5000 fonts you installed is damaged or not compatible with Windows XP. Figuring out which one(s) is the problem may not be an easy task, but I'd first suspect the last font listed in Photoshop CS, and the next font listed in your Fonts folder (listed alphabetically).

Welcome to the TCH family and forums, abutaleb!

Welcome to the forums, local1! The command should be set up in a cron job like this: >GET http://www.my-TCH-site.com/modules/MS_Analysis/include/cronmaintenance.php > /dev/null I tried using a GET command like the one above in a cron job on my account and I received the same error you did (/bin/sh: line 1: GET: command not found). The above is an alternate version of the following command, which does work on my account: >lwp-request -m GET http://www.my-TCH-site.com/modules/MS_Analysis/include/cronmaintenance.php > /dev/null Try that one and see if it works better for you.

Welcome to the family, Raj!

Welcome aboard, Ryan, and Congratulations!

Congratulations, Muhammad!

If I was going to have that much fun with them, I'd be tempted to use mod_rewrite to ban the IPs and redirect them to a custom 403 error page that only they would see. Then you wouldn't have to worry about innocent visitors accidentally seeing a page like Paul describes.

Actually, since the banned IP range is going to be added to the .htaccess file as a 'deny from' directive, I believe the correct way to add the range would be just "123.456".

Welcome to the forums, gigantor! I'm seeing this for the link to your stylesheet on your main weblog page: >http:// www.guzmanpdx.net/public_html/styles-site.css In Weblog Config, you need to fix the Site URL: 1) Remove the space from between the 'http://' and the 'www'. 2) Remove the 'public_html'. The Site URL setting should look like this: >http://www.guzmanpdx.net/ The Archive URL setting also needs to be corrected as well - you need to remove the space from between the 'http://' and the 'www'. It should look like this: >http://www.guzmanpdx.net/archives/ Save theses changes, then rebuild your entire weblog.

You may want to look at the "FrontPage Extensions" in CPanel and see if it showing the extensions as installed. Unless you've made any changes yourself, the .htaccess file should only contain directives pertaining to the use of the FrontPage extensions. Uninstalling the extensions from CPanel should delete the folders, files, and the .htaccess file from your public_html directory. As TCH-Thomas said, you should leave the cgi-bin directory in place.

I'm not sure what page you're looking at when you say "after choosing my table", so I'll start from the beginning in phpMyAdmin: 1) Select the database containing the table you want to move from the drop-down box on the left side of the page. 2) Select table you want to move by clicking its link on the left side of the page. 3) You should see the structure of the table you want to move, and a list of tabs going across the page above the structure. Click on the "Operations" tab. 4) On this page you should see "Move table to (database.table):" for the third option. Select the database you want to move the table into from the drop-down, and optionally specify a different name for the table in the new database, then click "Go". Hope this helps...

Case matters - you should use the following for CGIPath: >CGIPath http://www.tangentjournalism.com/mt/

Welcome to the forums, Darrien! Usually, 404 errors with mt.cgi pages indicate a problem with the CGIPath setting in your mt.cfg file. If you can post what have for your CGIPath setting, it should be pretty easy to figure out what's wrong with it.

Welcome to the forums, Andy!

Welcome to the forums, Eran! I've never installed or used phpBB, but it appears you need to download and install the language pack for Hebrew (and its related subSilver package), which you can find here.