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

On 3/22/10 3:42 AM, Guilhem Bichot wrote:
> 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.
>

I meant to use "./f", so it should be FN_CURLIB

The problem here is that "CURLIB" and "HOMELIB" are just names that 
means nothing, at least to me.
I guess next time I will keep a plain and simple hard coded ".", at 
least everyone knows what it is ...

Thanks for spotting this.

Regards,
-- Marc

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