MIME-Version: 1.0
In-Reply-To: <83haxvxegr.fsf@gnu.org>
References: <201203111650 DOT 53344 DOT juan DOT guerrero AT gmx DOT de>
	<83haxvxegr DOT fsf AT gnu DOT org>
Date: Thu, 29 Mar 2012 13:03:11 +0300
Message-ID: <CAA2C=vDw6_=TVAUpsAa=WgB0-MpbBLNZJop_d1KjyFADXYUsNA@mail.gmail.com>
Subject: Re: Value stored in cache_blksize if _is_remote_drive fails
From: Ozkan Sezer <sezeroz AT gmail DOT com>
To: djgpp-workers AT delorie DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

On Sun, Mar 11, 2012 at 6:57 PM, Eli Zaretskii <eliz AT gnu DOT org> wrote:
>> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
>> Date: Sun, 11 Mar 2012 16:50:53 +0100
>>
>>   if (!cache_blksize[d])
>>   {
>>     if (_is_remote_drive(d))  /* A = 0, B = 1, C = 2,  etc. */
>>     {
>>       /* Default remote drives to 4K block size, to improve performance.
>>        *
>>        * Also the size returned by statfs() may not be correct. Testing
>>        * against files shared by Samba 2.0.10 on Linux kernel 2.2.19
>>        * returned a 32K block size, even though the ext2 filesystem
>>        * holding the share share had a 4K block size. */
>>       cache_blksize[d] = 4096;
>>     }
>>     else
>>     {
>>       /* No entry => retrieve cluster size */
>>       if (statfs(path, &sbuf) != 0)
>>       {
>>         /* Failed, pass error through */
>>         return -1;
>>       }
>>
>>       cache_blksize[d] = sbuf.f_bsize;
>>     }
>>   }
>> -- code end --
>>
>>
>> If _is_remote_drive returns with a value different from 0 then cache_blksize[d]
>> is set to 4096.  The issue is that _is_remote_drive may return with 1 if d is a
>> remote drive but also it may return with -1 if the function fails for drive
>> number d.  In both cases cache_blksize[d] = 4096.  The question arises if this
>> is a bug or a feature?  Drive "d" does not exist but a valid block size is
>> assigned to cache_blksize[d] at the same time the errno (= ENODEV) set by
>> _is_remote_drive may get lost in future operations.
>
> There's not enough context in what you show to make up my mind whether
> this is a bug or a feature.  Specifically, it's not clear why it would
> be better to do something different when _is_remote_drive fails.
>
> Perhaps you could show a couple of use cases where this does some
> harm.
>
> Thanks.

What is the status of this issue?

--
O.S.