Ed Ravin [EMAIL PROTECTED] wrote:
15 years ago, Novell Netware started to return a fixed size of 512 for all
directories via NFS.
If there is still unfixed code, there is no help.
The Novell behavior, commendable as it is, did not break the BSD scandir()
code, because BSD scandir()
On 14 June, 2007 - Bill Sommerfeld sent me these 0,6K bytes:
On Thu, 2007-06-14 at 09:09 +0200, [EMAIL PROTECTED] wrote:
The implication of which, of course, is that any app build for Solaris 9
or before which uses scandir may have picked up a broken one.
or any app which includes its own
My question: What apps are these? I heard mention of some SunOS 4.x
library. I don't think that's anywhere near important enough to warrant
changing the current ZFS behavior.
Not apps; NFS clients such as *BSD.
On Solaris the issue is next to non-existant (SunOS 4.x binaries using
I went hunting for more apps in the hundreds of ports installed at my
shop to see what our exposure was to the scandir() problem - much to
my surpise out of 700 or so ports, only a dozen or so used the libc
scandir(). A handful of mail programs had a vulnerable local
implementation of scandir()
On June 13, 2007 11:26:07 PM -0400 Ed Ravin [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 09:42:26PM -0400, Ed Ravin wrote:
As mentioned before, NetBSD's scandir(3) implementation was one. The
NetBSD project has fixed this in their CVS. OpenBSD and FreeBSD's
scandir() looks like another,
On June 13, 2007 11:26:07 PM -0400 Ed Ravin [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 09:42:26PM -0400, Ed Ravin wrote:
As mentioned before, NetBSD's scandir(3) implementation was one. The
NetBSD project has fixed this in their CVS. OpenBSD and FreeBSD's
scandir() looks like another,
Frank Cusack [EMAIL PROTECTED] wrote:
On June 13, 2007 11:26:07 PM -0400 Ed Ravin [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2007 at 09:42:26PM -0400, Ed Ravin wrote:
As mentioned before, NetBSD's scandir(3) implementation was one. The
NetBSD project has fixed this in their CVS. OpenBSD
On Thu, 2007-06-14 at 09:09 +0200, [EMAIL PROTECTED] wrote:
The implication of which, of course, is that any app build for Solaris 9
or before which uses scandir may have picked up a broken one.
or any app which includes its own copy of the BSD scandir code, possibly
under a different name,
On Fri, Jun 15, 2007 at 12:27:15AM +0200, Joerg Schilling wrote:
Bill Sommerfeld [EMAIL PROTECTED] wrote:
On Thu, 2007-06-14 at 09:09 +0200, [EMAIL PROTECTED] wrote:
The implication of which, of course, is that any app build for Solaris 9
or before which uses scandir may have picked up
[EMAIL PROTECTED] wrote:
I believe we should rather educate other people that st_size/24 is a bad
solution.
That's all well and good but fixing all clients, including potentially
really old ones, might not be feasible. Being correct doesn't help
our customers.
To summarize my
On Wed, Jun 13, 2007 at 05:27:18PM -0700, Matthew Ahrens wrote:
[EMAIL PROTECTED] wrote:
I believe we should rather educate other people that st_size/24 is a bad
solution.
That's all well and good but fixing all clients, including potentially
really old ones, might not be feasible.
On Wed, Jun 13, 2007 at 05:27:18PM -0700, Matthew Ahrens wrote:
To summarize my understanding of this issue: st_size on directories is
undefined; apps/libs which do anything other than display it are broken.
However, we should avoid exercising this bug in these broken apps if
possible.
Ed Ravin wrote:
As mentioned before, NetBSD's scandir(3) implementation was one. The
NetBSD project has fixed this in their CVS. OpenBSD and FreeBSD's scandir()
looks like another, I'll have to drop them a line.
...
Thanks much for investigating this and pushing for fixes!
--matt
On Wed, Jun 13, 2007 at 09:42:26PM -0400, Ed Ravin wrote:
As mentioned before, NetBSD's scandir(3) implementation was one. The
NetBSD project has fixed this in their CVS. OpenBSD and FreeBSD's scandir()
looks like another, I'll have to drop them a line.
I heard from an OpenBSD developer who
I believe we should rather educate other people that st_size/24 is a bad
solution.
That's all well and good but fixing all clients, including potentially
really old ones, might not be feasible. Being correct doesn't help
our customers.
Casper
___
Only one byte per directory entry? This confuses
programs that assume that the st_size reported for a
directory is a multiple of sizeof(struct dirent) bytes.
Sorry, but a program making this assumption is just flawed and should be fixed.
The POSIX standard is crystal-clear here and
Frank Batschulat [EMAIL PROTECTED] wrote:
Only one byte per directory entry? This confuses
programs that assume that the st_size reported for a
directory is a multiple of sizeof(struct dirent) bytes.
Sorry, but a program making this assumption is just flawed and should be
fixed.
On Mon, 2007-06-11 at 00:57 -0700, Frank Batschulat wrote:
a directory is strictly speaking not a regular file and this is in a way
enforced by ZFS,
the standards wording further defines later on..
So, yes, the standards allow this behavior -- but it's important to
distinguish between
Maybe some additional pragmatism is called for here. If we want NFS
over ZFS to work well for a variety of clients, maybe we should set
st_size to larger values..
+1; let's teach the admins to do st_size /= 24 mentally :-)
Casper
___
zfs-discuss
On Mon, 2007-06-11 at 23:03 +0200, [EMAIL PROTECTED] wrote:
Maybe some additional pragmatism is called for here. If we want NFS
over ZFS to work well for a variety of clients, maybe we should set
st_size to larger values..
+1; let's teach the admins to do st_size /= 24 mentally :-)
Mental
Bill Sommerfeld [EMAIL PROTECTED] wrote:
On Mon, 2007-06-11 at 23:03 +0200, [EMAIL PROTECTED] wrote:
Maybe some additional pragmatism is called for here. If we want NFS
over ZFS to work well for a variety of clients, maybe we should set
st_size to larger values..
+1; let's teach the
Jeff Bonwick [EMAIL PROTECTED] wrote:
What was the reason to make ZFS use directory sizes as the number of
entries rather than the way other Unix filesystems use it?
In UFS, the st_size is the size of the directory inode as though it
were a file. The only reason it's like that is that UFS
What was the reason to make ZFS use directory sizes as the number of
entries rather than the way other Unix filesystems use it? I fear that
several more of the 700 open source packages we've ported to our hosts
are going to exhibit this problem.
It's a choice as good as any.
The scandir
[EMAIL PROTECTED] wrote:
On Sat, Jun 09, 2007 at 10:16:34PM +0200, [EMAIL PROTECTED] wrote:
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
ZFS. Any word on when the fix will be out?
It's a bug in scandir (obviously) and it is filed as such.
Does scandir
On 9/6/07 10:01, Eric Schrock [EMAIL PROTECTED] wrote:
On Sat, Jun 09, 2007 at 01:56:35PM -0700, Ed Ravin wrote:
I encountered the problem in NetBSD's scandir(), when reading off
a Solaris NFS fileserver with ZFS filesystems. I've already filed a
bug report with NetBSD. They were using
On 9/6/07 10:01, Eric Schrock [EMAIL PROTECTED] wrote:
On Sat, Jun 09, 2007 at 01:56:35PM -0700, Ed Ravin wrote:
I encountered the problem in NetBSD's scandir(), when reading off
a Solaris NFS fileserver with ZFS filesystems. I've already filed a
bug report with NetBSD. They were using
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in ZFS.
Any word on when the fix will be out?
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
ZFS. Any word on when the fix will be out?
It's a bug in scandir (obviously) and it is filed as such.
Does scandir fail on zfs because of this or does scandir needs to
reallocate and does it use the size as first order
On Sat, Jun 09, 2007 at 10:16:34PM +0200, [EMAIL PROTECTED] wrote:
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
ZFS. Any word on when the fix will be out?
It's a bug in scandir (obviously) and it is filed as such.
Does scandir fail on zfs because of this or
[EMAIL PROTECTED] wrote:
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
ZFS. Any word on when the fix will be out?
It's a bug in scandir (obviously) and it is filed as such.
A very old bug. I fixed it for a Berthold AG customer in 1992
when Novell Netware did start
On Sat, Jun 09, 2007 at 10:16:34PM +0200, [EMAIL PROTECTED] wrote:
Oh, I see, this is bug 6479267: st_size (struct stat) is unreliable in
ZFS. Any word on when the fix will be out?
It's a bug in scandir (obviously) and it is filed as such.
Does scandir fail on zfs because of this or does
On Sat, Jun 09, 2007 at 02:01:35PM -0700, Eric Schrock wrote:
On Sat, Jun 09, 2007 at 01:56:35PM -0700, Ed Ravin wrote:
I encountered the problem in NetBSD's scandir(), when reading off
a Solaris NFS fileserver with ZFS filesystems. I've already filed a
bug report with NetBSD. They
What was the reason to make ZFS use directory sizes as the number of
entries rather than the way other Unix filesystems use it?
In UFS, the st_size is the size of the directory inode as though it
were a file. The only reason it's like that is that UFS is sloppy
and lets you cat directories --
33 matches
Mail list logo
