Bug #16750 backup command not working when destination is mapped network drive
Submitted: 24 Jan 2006 15:42 Modified: 24 Jan 2006 21:52
Reporter: Thomas Nadeau Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server Severity:S3 (Non-critical)
Version:4.1.15 OS:Windows (Windows XP Professional)
Assigned to: CPU Architecture:Any

[24 Jan 2006 15:42] Thomas Nadeau
It seems that issuing the SQL backup command does not backup any files if the destination disk is a mapped network drive. No files are created in the destination folder. Here's an example that doesn't work on our system ("U:" is a mapped network drive):

lock tables alert_data read;
backup table alert_data to 'U:\\TomTest\\backup2006_01_23_150550';
unlock tables;

The backup command results in the following:

| Table                   | Op     | Msg_type | Msg_text                             |
| ubiquiti_110.alert_data | backup | error    | Failed copying .frm file (errno: 13) |
| ubiquiti_110.alert_data | backup | status   | Operation failed                     |

If we issue the same commands with a local disk, everything works fine. This works:

lock tables alert_data read;
backup table alert_data to 'C:\\TomTest\\backup';
unlock tables;

The permissions are the same for the destination directories on both the C and the U drives. From Windows explorer, if I right-click either destination directory, click "properties" and look at the "security" tab, it shows that everyone is allowed all permissions. If I go to a DOS prompt, and issue a "ls -l" command (I have Cygwin bash shell installed), I get the following entries:
drwxr-xr-x    1 Administ None            0 Jan 23 15:10 backup2006_01_23_150550
drwxr-xr-x    2 Administ None            0 Jan 23 15:14 backup

The "U" drive uses the NTFS file system, whereas the "C" drive uses FAT32.

The same backup problem also exists if we use MySQL version 1.0.17 from a Windows 2000 machine.

How to repeat:
-Map to a network drive that uses the NTFS file system (it's not clear if it's the mapped network drive, the NTFS file system, or the combination that may be the problem). Name the drive "U:".
-Create a directory named "U:\test_dir". Allow everyone all permissions.
-From a Windows machine (we tried Windows XP and Windows 2000), create a table named "test_table" in a MySQL database (we used MySQL versions 4.1.15 and 4.0.17). The table contents don't matter.
-Issue the following SQL queries against the database:

lock tables test_table read;
backup table test_table to 'U:\\test_dir';
unlock tables;

If the problem is duplicated, you should see an error on the backup command (see description portion of bug report), and "U:\test" will contain no files.

Suggested fix:
The backup command should function the same regardless of the destination disk, provided the permissions on the destination directories are the same.
[24 Jan 2006 16:21] Valeriy Kravchuk
Thank you for a problem report. Please, check that how your MySQL server is running. I believe, it is a service (correct me, if it is not the case). Services are, by default, running as LocalSystem. Can you copy files to that mapped network share from some user, say, user1 (in cmd.exe, using the copy command? If yes, try to run your MySQL server under the same user account and inform, is it possible to perform backup after that.
[24 Jan 2006 19:36] Thomas Nadeau
Yes, running the MySQL service under a different username solves the problem. Thank you Valeriy!
[24 Jan 2006 21:52] MySQL Verification Team
Thank you for the feedback.