Bug #17017 can lock the database in order to build a tar archive

Description:
in order to setup my replication, I want to backup the data repository after locking the database.
So, in another console, I lock with  FLUSH TABLES WITH READ LOCK;  but unfortunatly, tar reports an error because data/ibdata1 has changed during the processing of the tar command.
So, it appears that  FLUSH TABLES WITH READ LOCK;  does not really lock the database.
If I shutdown the master to have a safety save, I lost the information of the master status and later on the slave,  I cannot change the master host to  'master'  because when I start again the master, the position and the file have changed. 
data/ibdata1 seems used for innodb tables but how to lock innodb stuff ?

How to repeat:
in a mysql session, type 
 FLUSH TABLES WITH READ LOCK; 
in another session, type tar zcvf mydata.tgz data  
when processing data/ibdata1, you have an error message from tar saying that the file has changed during operation.
of course, database is in production !

Suggested fix:
method to really block the database ?

exact version is 4.1.8 and the database is a mixed set of isam and innodb tables

We're sorry, but the bug system is not the appropriate forum for 
asking help on using MySQL products. Your problem is not the result 
of a bug.

Support on using our products is available both free in our forums
at http://forums.mysql.com and for a reasonable fee direct from our
skilled support engineers at http://www.mysql.com/support/

Thank you for your interest in MySQL.