On Sunday 22 April 2007 11:10, Christoph Hellwig wrote:
> So what about stopping the flaming here and implementing real statvfs/
> fstatvfs syscalls instead of these horrible hacks glibc has to do
> currently?
I could imagine two approaches to that: either add statvfs and fstatvfs
syscalls, or
On Sat, Apr 21, 2007 at 09:04:06PM +0200, Andreas Gruenbacher wrote:
> > It is unspecified whether all members of the statvfs structure have
> > meaningful values on all file systems.
>
> In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts
> by far outweighs the
On Sat, Apr 21, 2007 at 09:04:06PM +0200, Andreas Gruenbacher wrote:
It is unspecified whether all members of the statvfs structure have
meaningful values on all file systems.
In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts
by far outweighs the problems is
On Sunday 22 April 2007 11:10, Christoph Hellwig wrote:
So what about stopping the flaming here and implementing real statvfs/
fstatvfs syscalls instead of these horrible hacks glibc has to do
currently?
I could imagine two approaches to that: either add statvfs and fstatvfs
syscalls, or use
On 4/21/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
What I described is a supported feature, nothing more and nothing less. It's
also relatively easy to handle this case correctly in glibc, e.g., [...]
This is only useful if the requirement of an ordered /proc/mounts is
part of the
On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > The code also seems to stop at the first matching mount point. You can
> > have the same device mounted on the same mount point multiple times but
> > with different mount options,
On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
The code also seems to stop at the first matching mount point. You can
have the same device mounted on the same mount point multiple times but
with different mount options, e.g.,
On 4/21/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
What I described is a supported feature, nothing more and nothing less. It's
also relatively easy to handle this case correctly in glibc, e.g., [...]
This is only useful if the requirement of an ordered /proc/mounts is
part of the kernel
> > I gave a chroot example that showed that in the current
> > implementation, you can get pretty random clashes between mounts; there are
> > other cases with lazy unmounts as well.
>
> Irrelevant as well. If you create chroot problems it's your problem.
>
> The fact is that if you have a
On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
The code also seems to stop at the first matching mount point. You can have
the same device mounted on the same mount point multiple times but with
different mount options, e.g., [...]
You can unfortunately do many stupid things.
On Friday 20 April 2007 17:24, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > Yes, that one, sorry. The values it obtains that way are not reliable.
>
> Why should the mount point info together with the filesystem type not
> be reliable?
Ah ... I overlooked
On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
Possibly for fstatfs(): fstatfs() has no way of looking up mount points per
path name in /proc/mounts, and so it resorts to mapping from the numeric
statfs->f_type to the filesystem name (e.g., "ext3"), looks up the first
mount point
On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
Yes, that one, sorry. The values it obtains that way are not reliable.
Why should the mount point info together with the filesystem type not
be reliable? You're trying to find an excuse to break tings, that
seems all there is.
-
To
On Friday 20 April 2007 17:15, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > Possibly for fstatfs(): fstatfs() has no way of looking up mount points
> > per path name in /proc/mounts, and so it resorts to mapping from the
> > numeric statfs->f_type to the
On Friday 20 April 2007 11:30, Alan Cox wrote:
> > As far as I can see, glibc internally looks at /proc/mounts (or else
> > mtab) to find out where tmpfs is mounted for opening files there, and to
> > look up filesystem information for statfs(), while accessing that path,
> > too. Fstatfs() also
> As far as I can see, glibc internally looks at /proc/mounts (or else mtab) to
> find out where tmpfs is mounted for opening files there, and to look up
> filesystem information for statfs(), while accessing that path, too. Fstatfs()
> also looks into the same files, but it only matches by
As far as I can see, glibc internally looks at /proc/mounts (or else mtab) to
find out where tmpfs is mounted for opening files there, and to look up
filesystem information for statfs(), while accessing that path, too. Fstatfs()
also looks into the same files, but it only matches by filesystem
On Friday 20 April 2007 17:15, Ulrich Drepper wrote:
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
Possibly for fstatfs(): fstatfs() has no way of looking up mount points
per path name in /proc/mounts, and so it resorts to mapping from the
numeric statfs-f_type to the filesystem
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
Yes, that one, sorry. The values it obtains that way are not reliable.
Why should the mount point info together with the filesystem type not
be reliable? You're trying to find an excuse to break tings, that
seems all there is.
-
To
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
Possibly for fstatfs(): fstatfs() has no way of looking up mount points per
path name in /proc/mounts, and so it resorts to mapping from the numeric
statfs-f_type to the filesystem name (e.g., ext3), looks up the first
mount point with
On Friday 20 April 2007 11:30, Alan Cox wrote:
As far as I can see, glibc internally looks at /proc/mounts (or else
mtab) to find out where tmpfs is mounted for opening files there, and to
look up filesystem information for statfs(), while accessing that path,
too. Fstatfs() also looks
On Friday 20 April 2007 17:24, Ulrich Drepper wrote:
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
Yes, that one, sorry. The values it obtains that way are not reliable.
Why should the mount point info together with the filesystem type not
be reliable?
Ah ... I overlooked that
On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote:
The code also seems to stop at the first matching mount point. You can have
the same device mounted on the same mount point multiple times but with
different mount options, e.g., [...]
You can unfortunately do many stupid things. That's
I gave a chroot example that showed that in the current
implementation, you can get pretty random clashes between mounts; there are
other cases with lazy unmounts as well.
Irrelevant as well. If you create chroot problems it's your problem.
The fact is that if you have a normal setup
On Tuesday 17 April 2007 19:21, Alan Cox wrote:
> Can you prove no existing application on the planet relies on the
> existing behaviour ? Actually more limited but sane as a test would be
> "Can you prove that the glibc behaviour visible to applications does not
> change"
As far as I can see,
On Tuesday 17 April 2007 19:21, Alan Cox wrote:
Can you prove no existing application on the planet relies on the
existing behaviour ? Actually more limited but sane as a test would be
Can you prove that the glibc behaviour visible to applications does not
change
As far as I can see, glibc
26 matches
Mail list logo
