Jump to content

Archived

This topic is now archived and is closed to further replies.

pmg206

Argh! Errcode: 13 and File Not Found on a Table

Recommended Posts

So, I'm parked on Yahoo! web hosting and using their MySQL offering (MySQL 4.1.14, PHP 4.3.11, admin tools phpMyAdmin 2.6.3-pl1).  Database is up, running, and groovy, with six tables.  After removing a default value in one field of the main data table, my internet conncetion did something curious, I landed with a 'Page Cannot be Displayed', and the table is now showing "in use" within phpMyAdmin, and a rash of goofyness from the PHP pages.

Using myPhpAdmin, if I attempt to access the Structure tab, I end up with the error below (obviously, "films" is the database and "titles" is the table):
---------------------------------------------------------------
File './films/titles.MYD' not found (Errcode: 13)

Error
SQL query:
SHOW KEYS FROM `titles` ;

MySQL said: 
#1105 - File './films/titles.MYD' not found (Errcode: 13)
---------------------------------------------------------------

Most of the PHP pages that would otherwise be accessible are now showing this message:
---------------------------------------------------------------
File './films/titles.MYD' not found (Errcode: 13)
---------------------------------------------------------------

My RTFM on Google mostly posted to a permissions issue, though not too much feedback as to HOW to address it.  I did try to use the Repair Database utility from Yahoo! (myisamchk is what they'll run on my behalf), to no avail.

I have a valid backup (10 days old), so reloading and recreating 10 days' work is possible, though my Plan B. 

Looking for a whiz bang Plan A, ideally, of course, or any suggestions for a Plan A and a Half.  I do have access to command-line SQL within myPhpAdmin, though no server access, since it's a Yahoo! thing.  Thanks!

Share this post


Link to post
Share on other sites
What does CHECK TABLES say about this particular table?  You may simple be able to "repair" it, provided that data is ok, or rebuild the index portion alone.

Share this post


Link to post
Share on other sites
Presuming I've done this correctly (grabbing the details from theMySQL 3.23, 4.0, 4.1 online reference), this is the query and result:

SQL query 
SQL query:  CHECK TABLE titles FAST 

RESULTS (underscores added to align header and result row data):
-----------------------------------------------------------------------------------
Table_______ Op_____  Msg_type____ Msg_text 
films.titles___ check___ error________ File './films/titles.MYD' not found (Errcode: 13)
-----------------------------------------------------------------------------------

Running a CHECK TABLE titles EXTENDED had a similar result, as did REPAIR TABLE...

Share this post


Link to post
Share on other sites
I assume the file is actually there still?

Share this post


Link to post
Share on other sites
I certainly hope so (not a team or shared environment, but when the internet connection bounced, who knows how the server side at Yahoo! took the command).

The database's other tables are available and accessible.  This table is showing in the myPhpAdmin screen as present, but instead of the count of rows in the table and all the icons available, the row count shows "in use" and roughly half of the icons (browse, search, empty) are grayed out.  Of those visible for use (insert, structure, delete), insert and structure both return a "#1105 - File './films/titles.MYD' not found (Errcode: 13)" error, and I don't plan on hitting the delete... yet.

Grrr... but perhaps that Plan B with the oldish backup is going to become the path of lesser resistance in the greater scheme of things...

Share this post


Link to post
Share on other sites
So, it's happy again, as tables go.  After all the silliness and check and repair commands, I took another backup with the Yahoo! tools, compared the sizes of the MYD and MYI files to confirm they were (a) there, and (b) bigger than the last known good backup, and they were.  Figuring why not, I restored that database backup over the "in use" table (and others, of course), and it's happy again.

Thanks for the feedback as I sorted this one out (with your suggestions, of course!).  :)

Share this post


Link to post
Share on other sites

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.