> Be careful with e2fsprogs/glibc on partitions > 2GB. The latest e2fsprogs
> in Debian (which uses glibc) is affected by a bug (I think) in llseek.
> I effectively destroyed one 2.5GB partition I had by using e2fsck on it...
>
> This is due to glibc not declaring llseek() in the system include
> headers. I have a philosophical difference of opinion with the glibc
> developers. My take is that if it's in the global namespace as
> llseek(), it should be defined in the header files; that's how Solaris
> and Linux libc4 handled things.
Yes, but llseek() is in no way a standard function, so it shouldn't litter the
namespace of a highly portable library - such as glibc.
> Their take is that they think it should be an internal interface, and
> not defined in the header files.... as far as I'm concerned, I could
> agree with that, except then llseek() should be _llseek() instead.
I agree with both points of view here - it should be internal and it should be
_llseek().
> Anyway, the root cause of the problem is that libc 5 defines llseek() in
> the system header files, and glibc does not. This causes the
> ext2_llseek() routine to be compiled incorrectly under glibc, since a
> long long argument is getting treated as an int.
>
> It'll get fixed in the next version of e2fsprogs; until then, add
>
> #undef HAVE_LLSEEK
>
> to the beginning of lib/ext2fs/llseek.c, or simply compile e2fsprogs
> with libc 5.
I'll take the first approach - no more libc5 ;-)))
P.S. Ted, I have ported e2fsprogs ext2fs library to DOS, would you care to
have the difs?