On 4/3/13 3:49 AM, Florian Weimer wrote:
> On 02/19/2013 12:15 AM, Eric Sandeen wrote:
>> On 2/18/13 5:11 PM, John Reiser wrote:
>>> It would be useful to have a "backward compatibility" LD_PRELOAD shared
>>> library which intercepts the caller of stat32, and sets .st_ino to 0,
>>> without generati
On 02/19/2013 12:15 AM, Eric Sandeen wrote:
On 2/18/13 5:11 PM, John Reiser wrote:
It would be useful to have a "backward compatibility" LD_PRELOAD shared
library which intercepts the caller of stat32, and sets .st_ino to 0,
without generating EOVERFLOW, whenever the actual inode number exceeds
On Tue, 2013-02-19 at 17:09 +0100, Jakub Jelinek wrote:
> On Tue, Feb 19, 2013 at 05:04:43PM +0100, Florian Weimer wrote:
> > On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
> > >On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
> > >>>(3) For my code that uses st_ino, I need to ensure thi
On 02/18/2013 03:15 PM, Eric Sandeen wrote:
> On 2/18/13 5:11 PM, John Reiser wrote:
>> It would be useful to have a "backward compatibility" LD_PRELOAD shared
>> library ...
> Yep, that would make some sense as a workaround. ...
As proof of concept, I have constructed such a wrapper shared libr
On 02/20/2013 05:33 PM, Jakub Jelinek wrote:
Of course, the script needs to be smart, because e.g. glibc will always
contain __xstat symbol, as it is part of the exported ABI.
It's sufficient to consider references only, definitions don't count. I
believe Eric's script does exactly that. (sy
On Wed, Feb 20, 2013 at 09:40:00AM -0600, Eric Sandeen wrote:
> I really don't think it's safe to add -D_FILE_OFFSET_BITS=64 to the
> default CFLAGS. Code will start getting bigger numbers and will
> need to cope appropriately lest they overflow. It'd be draconian
> but I'd prefer to do somethin
On 2/20/13 8:23 AM, Chris Adams wrote:
> Once upon a time, Bill Nottingham said:
>> Florian Weimer (fwei...@redhat.com) said:
>>> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
>>> pretty close to an ABI bump. But considering the numbers, I wonder
>>> if it's the right thing t
On Wed, Feb 20, 2013 at 01:23:56PM +, Richard Hughes wrote:
> On 20 February 2013 10:32, Florian Weimer wrote:
> > If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes pretty
> > close to an ABI bump. But considering the numbers, I wonder if it's the
> > right thing to do if we n
Once upon a time, Bill Nottingham said:
> Florian Weimer (fwei...@redhat.com) said:
> > If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
> > pretty close to an ABI bump. But considering the numbers, I wonder
> > if it's the right thing to do if we need to cope with 64-bit inode
On Wed, Feb 20, 2013 at 09:01:30AM -0500, Colin Walters wrote:
> The first option on the table should be patching upstreams, not hacking
> around it in RPM or changing the default.
>
> With autoconf, all you need is to add AC_SYS_LARGEFILE to configure.ac,
> and assuming no source changes are nece
On Wed, 2013-02-20 at 14:43 +0100, Joe Orton wrote:
> If we want the "system default" for the LFS APIs to change, surely it is
> safer and more correct to change the system (libc) default and have
> _FILE_OFFSET_BITS defined to 64 eveywhere?
The first option on the table should be patching upst
On Wed, Feb 20, 2013 at 11:32:46AM +0100, Florian Weimer wrote:
> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
> pretty close to an ABI bump. But considering the numbers, I wonder
> if it's the right thing to do if we need to cope with 64-bit inode
> numbers.
I think that wou
On 20 February 2013 10:32, Florian Weimer wrote:
> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes pretty
> close to an ABI bump. But considering the numbers, I wonder if it's the
> right thing to do if we need to cope with 64-bit inode numbers.
I think this is the sanest thing
On Wed, Feb 20, 2013 at 2:17 PM, Bill Nottingham wrote:
> Miloslav Trmač (m...@volny.cz) said:
>> That would be very useful.
>>
>> 1) Easy: run a script to find affected packages and auto-file bugs.
>> 2) Fairly possible: get at least the important packages fixed in F19
>> (or, 1+2: change default
Miloslav Trmač (m...@volny.cz) said:
> That would be very useful.
>
> 1) Easy: run a script to find affected packages and auto-file bugs.
> 2) Fairly possible: get at least the important packages fixed in F19
> (or, 1+2: change default build configuration to cover most packages,
> and rebuild.)
>
On Mon, Feb 18, 2013 at 10:33 PM, Eric Sandeen wrote:
> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
> inode numbers creep past 2^32 as well.
>
> While most applications don't care one bit about st_ino returned from a
> stat() call, the sad fact is that you'll get
On Tue, Feb 19, 2013 at 5:04 PM, Florian Weimer wrote:
> On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
>>
>> On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
(3) For my code that uses st_ino, I need to ensure this is never
assigned to a 32 bit integer (eg. 'int', 'int32_
Florian Weimer (fwei...@redhat.com) said:
> On 02/18/2013 10:33 PM, Eric Sandeen wrote:
>
> >XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
> >inode numbers creep past 2^32 as well.
> >
> >While most applications don't care one bit about st_ino returned from a
> >s
> On Tue, 19 Feb 2013 20:13:23 +0900, Mamoru TASAKA wrote:
>
> > Well, cifs-mounted filesystem already returns such large inode, and
> > xscreensaver
> > already suffered from this issue.
> > https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/609451/comments/11
>
> About your recent com
On Tue, 19 Feb 2013 20:13:23 +0900, Mamoru TASAKA wrote:
> Well, cifs-mounted filesystem already returns such large inode, and
> xscreensaver
> already suffered from this issue.
> https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/609451/comments/11
About your recent comment there on AC
On Mon, 18 Feb 2013 19:37:05 -0500, Sam Varshavchik wrote:
> Eric Sandeen writes:
>
> > and it's not just weird obscure packages:
> >
> > # ./summarize-stat.pl `rpm -ql sendmail`
>
> This is not accurate. -ql will also list directories, and summarize-stat.pl
> then proceeds to chew on every fi
Petr Pisar wrote:
> Is %configure spec macro the right place to define FILE_OFFSET_BITS?
I'd suggest throwing it into %{_optflags}.
FWIW, all KDE software is already built with -D_FILE_OFFSET_BITS=64,
FindKDE4Internal.cmake forces it (unless off_t is already 64-bit by
default). (Of course, this
On 2/19/13 9:22 AM, Eric Sandeen wrote:
> On 2/19/13 4:46 AM, Richard W.M. Jones wrote:
>> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
>>> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs
>>> can let inode numbers creep past 2^32 as well.
>>>
>>> While most app
On 02/19/2013 05:09 PM, Jakub Jelinek wrote:
You can't use ino_t and off_t in public header files because of that
_FILE_OFFSET_BITS dependency. At least in such header files, using
explicit 64-bit types (uint64_t, presumably) is the way to go.
You can use it in public header files just fine,
On Tue, Feb 19, 2013 at 05:04:43PM +0100, Florian Weimer wrote:
> On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
> >On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
> >>>(3) For my code that uses st_ino, I need to ensure this is never
> >>>assigned to a 32 bit integer (eg. 'int', 'int32_
On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
(3) For my code that uses st_ino, I need to ensure this is never
assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
To be safe I'd use it in an u64 type, I guess
On 2/19/13 9:32 AM, Jakub Jelinek wrote:
> On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
>>> (3) For my code that uses st_ino, I need to ensure this is never
>>> assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
>>
>> To be safe I'd use it in an u64 type,
On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
> > (3) For my code that uses st_ino, I need to ensure this is never
> > assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
>
> To be safe I'd use it in an u64 type, I guess. The *internal* kernel stat
> struc
On 2/19/13 4:46 AM, Richard W.M. Jones wrote:
> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
>> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs
>> can let inode numbers creep past 2^32 as well.
>>
>> While most applications don't care one bit about st_ino retur
On 2/19/13 6:48 AM, Petr Pisar wrote:
> On 2013-02-18, Eric Sandeen wrote:
>>
>> Anyway, if you want to check your package(s) and maybe make them
>> 64-bit-stat safe, the perl script above might help. It's more than
>> just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to
>> overflow an
On 2013-02-19, Richard W.M. Jones wrote:
> On Tue, Feb 19, 2013 at 12:33:07PM +, Petr Pisar wrote:
>> EOVERFLOW
>> (stat()) path refers to a file whose size cannot be represented
>> in the type off_t. This can occur when an application compiled
>> on a 32-bit platform with
On Tue, Feb 19, 2013 at 12:33:07PM +, Petr Pisar wrote:
> EOVERFLOW
> (stat()) path refers to a file whose size cannot be represented
> in the type off_t. This can occur when an application compiled
> on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat()
>
On 2013-02-18, Eric Sandeen wrote:
>
> Anyway, if you want to check your package(s) and maybe make them
> 64-bit-stat safe, the perl script above might help. It's more than
> just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to
> overflow any large values you get back from stat64 etc.
On 2013-02-19, Richard W.M. Jones wrote:
> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
> (1) Just ensuring the code is compiled with -DFILE_OFFSET_BITS=64 is
> sufficient to ensure the 32 bit stat will never be called, right?
>
I think so.
> (2) If my code never mentions st_ino,
Eric Sandeen wrote, at 02/19/2013 06:33 AM +9:00:
XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
inode numbers creep past 2^32 as well.
While most applications don't care one bit about st_ino returned from a stat()
call, the sad fact is that you'll get EOVERFLOW fro
On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs
> can let inode numbers creep past 2^32 as well.
>
> While most applications don't care one bit about st_ino returned
> from a stat() call, the sad fact is that you'l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/18/13 6:37 PM, Sam Varshavchik wrote:
> Eric Sandeen writes:
>
>> and it's not just weird obscure packages:
>>
>> # ./summarize-stat.pl `rpm -ql sendmail`
>
> This is not accurate. -ql will also list directories, and summarize-stat.pl
> then pr
Eric Sandeen writes:
and it's not just weird obscure packages:
# ./summarize-stat.pl `rpm -ql sendmail`
This is not accurate. -ql will also list directories, and summarize-stat.pl
then proceeds to chew on every file in that directory.
pgp3mZDihNsQh.pgp
Description: PGP signature
--
dev
On 2/18/13 5:11 PM, John Reiser wrote:
> On 02/18/2013 01:33 PM, Eric Sandeen wrote:
>> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
>> inode numbers creep past 2^32 as well.
>>
>> While most applications don't care one bit about st_ino returned from a
>> stat() ca
On 02/18/2013 01:33 PM, Eric Sandeen wrote:
> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
> inode numbers creep past 2^32 as well.
>
> While most applications don't care one bit about st_ino returned from a
> stat() call, the sad fact is that you'll get EOVERFLOW
XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
inode numbers creep past 2^32 as well.
While most applications don't care one bit about st_ino returned from a stat()
call, the sad fact is that you'll get EOVERFLOW from stat32 if the inode number
is too big to fit in
41 matches
Mail list logo
