Bug #159 mysqldump --first-slave or --master-data silently purges master's binlogs

Description:
mysqldump --first-slave or --master-data silently send RESET MASTER (FLUSH MASTER
in fact, which is an alias) to the master. So the master's binlogs silently get
deleted. Even if this is relatively safe, as we've just dumped the master's data
(provided we dumped all databases : mysqldump --master-data this_db is allowed!),
the user may strongly not want it. And anyway it is a bug as just before purging,
mysqldump prints CHANGE MASTER statements which contain the current binlog
coordinates, which become bogus as soon as RESET MASTER is completed.
When fed in the slave, these CHANGE MASTER will produce errors like :
030317 15:54:09  Slave I/O thread: connected to master 'root@localhost:3306',  replication started in log 'gbichot-bin.001' at position 131
030317 15:54:09  Error reading packet from server: Client requested master to start replication from impossible position (server_errno=1236)
030317 15:54:09  Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
030317 15:54:09  Slave I/O thread exiting, read up to log 'gbichot-bin.001', position 131

How to repeat:
1) I create a db on the master

create database test2;
show master status;
+-----------------+----------+--------------+------------------+
| File            | Position | Binlog_do_db | Binlog_ignore_db |
+-----------------+----------+--------------+------------------+
| gbichot-bin.001 | 131      |              |                  |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)

2) Then I do

mysqldump --master-data -uroot test2
-- MySQL dump 9.07
--
-- Host: localhost    Database: test2
---------------------------------------------------------
-- Server version       4.0.12-debug-log

--
-- Position to start replication from
--

CHANGE MASTER TO MASTER_LOG_FILE='gbichot-bin.001' ;
CHANGE MASTER TO MASTER_LOG_POS=131 ;

3) then

show master status;
+-----------------+----------+--------------+------------------+
| File            | Position | Binlog_do_db | Binlog_ignore_db |
+-----------------+----------+--------------+------------------+
| gbichot-bin.001 | 79       |              |                  |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)

See how 131 became 79

Suggested fix:
simply remove this RESET MASTER, or better make it an option (off by default).

Thank you for your bug report. This issue has been fixed in the latest
development tree for that product. You can find more information about
accessing our development trees at 
    http://www.mysql.com/doc/en/Installing_source_tree.html

fixed in 3.23 and 4.0. New option --delete-master-logs for mysqldump