From: Date: November 5 2007 3:31pm
Subject: Re: bk commit into 5.0 tree (aelkin:1.2543) BUG#28597
List-Archive: http://lists.mysql.com/commits/37092
Message-Id: <20071105143119.GB28179@janus.mylan>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi!

Ok to push without MY_UNPACK_FILENAME and with a shorter changeset
comment. See below.

On Nov 02, Andrei Elkin wrote:
> ChangeSet@stripped, 2007-11-02 11:15:05+02:00, aelkin@stripped +3 -0
>   Bug #28597 Replication doesn't start after upgrading to 5.1.18

Please, commit with the "DOCUMENATION proposal", changeset comment is
supposed to be short. Add this proposal to the bugreport instead.
   
>   Since bug@20166, which replaced the binlog file name generating to base
>   on pidfile_name instead of the previous glob_hostname, the binlog file
>   name suddenly started to be stored solely in the absolute path format,
>   including a case when --log-bin option meant a relative path.
>   What's more serious, the path for binlog file can lead unrequestedly 
>   to pid-file directory so that after any proper fix for this bug
>   there might be similar to the bug report consequences for one who
>   upgrades from post-fix-bug@20166-pre-fix-bug@28597 to post-fix-bug@28597.
>   
>   Fixed with preserving`pidfile_name' (intr.by bug@20166) but stripping
>   off its directory part. This restores the original logics of storing
>   the names in compatible with --log-bin option format and with the
>   requirement for --log-bin ralative path to corresond to the data directory.
>   Side effects for this fix:
>   
>   effective fixing bug@27070, refining its test;
>   ensuring no overrun for buff can happen anymore (Bug#31836 
>   insufficient space reserved for the suffix of relay log file name);
>   bug#31837  --remove_file $MYSQLTEST_VARDIR/tmp/bug14157.sql missed
>   in rpl_temporary.test;
>   fixes Bug@28603  Invalid log-bin default location;
>   
>   
>   DOCUMENATION proposal.
>   
>   
>   After upgrading either 5.0 or 5.1 master server from 
>   a post-fix-bug#20166 release, a slave can fail in requesting to
>   start dumping operation to receive the error
>   "Could not find first log file name in binary log index file".
>   
>   In such case conduct the following procedure:
>   
>   1.  make sure the binlog index file resides in the requested directory -
>       consider --datadir, --log-bin-index and --log-bin options.
>       If not - they might be in --pid-file's directory - manually copy them
>       to correspond to the options.
>   2.  make sure the binlog index file lists names in compatible to --log-bin
>       option format. If --log-bin is empty or means a relative path
>       (e.g --log-bin=master) then the names in the file should be in
>       the relative format such as
>   
>       ./your_hostname-bin.000001
>       ./your_hostname-bin.000002
>       ...
>   
>       or
>   
>       ./master-bin.000001
>       ./master-bin.000002
>       ...
> 
> diff -Nrup a/sql/log.cc b/sql/log.cc
> --- a/sql/log.cc	2007-07-30 18:27:30 +03:00
> +++ b/sql/log.cc	2007-11-02 11:15:01 +02:00
> @@ -448,13 +448,11 @@ const char *MYSQL_LOG::generate_name(con
>  {
>    if (!log_name || !log_name[0])
>    {
> -    /*
> -      TODO: The following should be using fn_format();  We just need to
> -      first change fn_format() to cut the file name if it's too long.
> -    */
> -    strmake(buff, pidfile_name,FN_REFLEN-5);
> -    strmov(fn_ext(buff),suffix);
> -    return (const char *)buff;
> +    strmake(buff, pidfile_name, FN_REFLEN - strlen(suffix) - 1);
> +    return (const char *)
> +      fn_format(buff, buff, "", suffix,
> +                MYF(MY_UNPACK_FILENAME|MY_REPLACE_EXT|MY_REPLACE_DIR));

Why do you need MY_UNPACK_FILENAME here ? It fixes the path by
removing ".." and "/./" and expanding "~/". But with MY_REPLACE_DIR you
remove the dirname of the path anyway.

Regards / Mit vielen Grüssen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Developer
/_/  /_/\_, /___/\___\_\___/  MySQL GmbH, Dachauer Str. 37, D-80335 München
       <___/                  Geschäftsführer: Kaj Arnö - HRB München 162140