Merge riska.(none):/home/sven/bk/b34355-backslash_in_path_name_under_win/5.0-rpl

into  riska.(none):/home/sven/bk/b34355-backslash_in_path_name_under_win/5.1-new-rpl


client/mysqlbinlog.cc:
  Auto merged
sql/slave.cc:
  Auto merged
sql/slave.h:
  Auto merged

client/mysqlbinlog.cc

@@ -475,6 +475,31 @@ Create_file event for file_id: %u\n",ae->file_id);
 Load_log_processor load_processor;
 
 
+/**
+  Replace windows-style backslashes by forward slashes so it can be
+  consumed by the mysql client, which requires Unix path.
+
+  @todo This is only useful under windows, so may be ifdef'ed out on
+  other systems.  /Sven
+
+  @todo If a Create_file_log_event contains a filename with a
+  backslash (valid under unix), then we have problems under windows.
+  /Sven
+
+  @param[in,out] fname Filename to modify. The filename is modified
+  in-place.
+*/
+static void convert_path_to_forward_slashes(char *fname)
+{
+  while (*fname)
+  {
+    if (*fname == '\\')
+      *fname= '/';
+    fname++;
+  }
+}
+
+
 static bool check_database(const char *log_dbname)
 {
   return one_database &&
@@ -627,6 +652,11 @@ int process_event(PRINT_EVENT_INFO *print_event_info, Log_event *ev,
       */
       if (ce)
       {
+        /*
+          We must not convert earlier, since the file is used by
+          my_open() in Load_log_processor::append().
+        */
+        convert_path_to_forward_slashes((char*) ce->fname);
 	ce->print(result_file, print_event_info, TRUE);
 	my_free((char*)ce->fname,MYF(MY_WME));
 	delete ce;
@@ -675,13 +705,7 @@ Create_file event for file_id: %u\n",exv->file_id);
 
       if (fname)
       {
-        /*
-          Fix the path so it can be consumed by mysql client (requires Unix path).
-        */
-        int stop= strlen(fname);
-        for (int i= 0; i < stop; i++)
-          if (fname[i] == '\\')
-            fname[i]= '/';
+        convert_path_to_forward_slashes(fname);
 	exlq->print(result_file, print_event_info, fname);
 	my_free(fname, MYF(MY_WME));
       }

sql/slave.cc

@@ -1337,14 +1337,15 @@ bool show_master_info(THD* thd, Master_info* mi)
     protocol->prepare_for_resend();
 
     /*
-      TODO: we read slave_running without run_lock, whereas these variables
-      are updated under run_lock and not data_lock. In 5.0 we should lock
-      run_lock on top of data_lock (with good order).
+      slave_running can be accessed without run_lock but not other
+      non-volotile members like mi->io_thd, which is guarded by the mutex.
     */
+    pthread_mutex_lock(&mi->run_lock);
+    protocol->store(mi->io_thd ? mi->io_thd->proc_info : "", &my_charset_bin);
+    pthread_mutex_unlock(&mi->run_lock);
+
     pthread_mutex_lock(&mi->data_lock);
     pthread_mutex_lock(&mi->rli.data_lock);
-
-    protocol->store(mi->io_thd ? mi->io_thd->proc_info : "", &my_charset_bin);
     protocol->store(mi->host, &my_charset_bin);
     protocol->store(mi->user, &my_charset_bin);
     protocol->store((uint32) mi->port);

sql/slave.h

@@ -80,8 +80,8 @@ class Master_info;
   mi->rli does not either.
 
   In Master_info: run_lock, data_lock
-  run_lock protects all information about the run state: slave_running, and the
-  existence of the I/O thread (to stop/start it, you need this mutex).
+  run_lock protects all information about the run state: slave_running, thd
+  and the existence of the I/O thread to stop/start it, you need this mutex).
   data_lock protects some moving members of the struct: counters (log name,
   position) and relay log (MYSQL_BIN_LOG object).