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
