List:Commits« Previous MessageNext Message »
From:Guilhem Bichot Date:March 22 2010 9:42am
Subject:Re: bzr commit into mysql-next-mr-bugfixing branch (marc.alff:3138)
Bug#52134
View as plain text  
Hello Marc,

Marc Alff a écrit, Le 22.03.2010 10:08:
> #At file:///Users/malff/BZR_TREE/mysql-next-mr-bugfixing-52134/ based on
> revid:jack@stripped
> 
>  3138 Marc Alff	2010-03-22
>       Bug#52134 performance schema file io, symlink in path
>       
>       Before this fix, a file named "/path/with/link/to/filename"
>       would be normalized to:
>       - "/path/with/link/to/filename" when the file did not exist (creation),
>       - "/real/path/to/filename" when the file did exist (file io, deletion),
>       causing instrumentation leak for file io in the performance schema.
>       
>       With this fix, file name normalization has been revisited to be more robust,
>       and always resolve this case to "/real/path/to/filename".

> === modified file 'storage/perfschema/pfs_instr.cc'
> --- a/storage/perfschema/pfs_instr.cc	2010-03-05 01:36:54 +0000
> +++ b/storage/perfschema/pfs_instr.cc	2010-03-22 09:08:28 +0000
> @@ -1,4 +1,4 @@
> -/* Copyright (C) 2008-2009 Sun Microsystems, Inc
> +/* Copyright (c) 2008, 2010 Oracle and/or its affiliates. All rights reserved.
>  
>    This program is free software; you can redistribute it and/or modify
>    it under the terms of the GNU General Public License as published by
> @@ -770,16 +770,55 @@ find_or_create_file(PFS_thread *thread, 

> +    When the last component of a file is a symbolic link,
> +    the last component is *not* resolved, so that all file io
> +    operations on a link (create, read, write, delete) are counted
> +    against the link itself, not the target file.
> +    Resolving the name would lead to create counted against the link,
> +    and read/write/delete counted against the target, leading to
> +    incoherent results and instrumentation leaks.

smart

>    char buffer[FN_REFLEN];
> +  char dirbuffer[FN_REFLEN];
> +  size_t dirlen;
>    const char *normalized_filename;
>    int normalized_length;
>  
> -  /*
> -    Ignore errors, the file may not exist.
> -    my_realpath always provide a best effort result in buffer.
> -  */
> -  (void) my_realpath(buffer, safe_filename, MYF(0));
> +  dirlen= dirname_length(safe_filename);
> +  if (dirlen == 0)
> +  {
> +    dirbuffer[0]= FN_HOMELIB;

I don't know what FN_HOMELIB (which seems to always be "~") will do on 
Windows? I'm only wondering, I have no idea.
And, is it sure that when I want to open file "f" I mean "~/f"? Maybe my 
code has done a chdir("d") before, so "f" means "d/f" and not "~/f"?
Shouldn't we use "./f", i.e. FN_CURLIB instead of FN_HOMELIB? I mean, 
just treat "f" as "./f" which I think is a safe assumption.

> +    dirbuffer[1]= FN_LIBCHAR;
> +    dirbuffer[2]= '\0';
> +  }
> +  else
> +  {
> +    memcpy(dirbuffer, safe_filename, dirlen);
> +    dirbuffer[dirlen]= '\0';
> +  }
> +
> +  if (my_realpath(buffer, dirbuffer, MYF(0)) != 0)
> +  {
> +    file_lost++;
> +    return NULL;
> +  }
> +
> +  /* Append the unresolved file name to the resolved path */
> +  char *ptr= buffer + strlen(buffer);
> +  *ptr++= FN_LIBCHAR;
> +  ptr= strmov(ptr, safe_filename + dirlen);
> +  *ptr= '\0';
>  
>    normalized_filename= buffer;
>    normalized_length= strlen(normalized_filename);
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 

-- 
Mr. Guilhem Bichot <guilhem@stripped>
Sun Microsystems / MySQL, Lead Software Engineer
Bordeaux, France
www.sun.com / www.mysql.com
Thread
bzr commit into mysql-next-mr-bugfixing branch (marc.alff:3138)Bug#52134Marc Alff22 Mar
  • Re: bzr commit into mysql-next-mr-bugfixing branch (marc.alff:3138)Bug#52134Guilhem Bichot22 Mar
    • Re: bzr commit into mysql-next-mr-bugfixing branch (marc.alff:3138)Bug#52134Marc Alff22 Mar
      • Re: bzr commit into mysql-next-mr-bugfixing branch (marc.alff:3138)Bug#52134Guilhem Bichot22 Mar