Bug 134311 - misc/gnuls: problems with gnuls -l on versions >= 7.x
Summary: misc/gnuls: problems with gnuls -l on versions >= 7.x
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Wesley Shields
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-06 22:50 UTC by Timothy Beyer
Modified: 2009-06-22 20:00 UTC (History)
1 user (show)

See Also:


Attachments
gnuls.diff (1.07 KB, patch)
2009-06-22 15:10 UTC, Wesley Shields
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Timothy Beyer 2009-05-06 22:50:01 UTC
On all of the 7.x ported versions of gnuls, ls -l indefinitely shows no output, and never returns.  I am not sure if others can reproduce this bug.  misc/gnuls version 6.12 works fine.

Fix: 

I am simply reporting this issue so that others may be aware of it, I'm not sure how to fix it.  (I wrote an alternative to emacs' dired, so I no longer have a need for GNU ls)
How-To-Repeat: on the shell,

gnuls -l

(my shell is tcsh)
Comment 1 Edwin Groothuis freebsd_committer 2009-05-06 22:50:10 UTC
Maintainer of misc/gnuls,

Please note that PR ports/134311 has just been submitted.

If it contains a patch for an upgrade, an enhancement or a bug fix
you agree on, reply to this email stating that you approve the patch
and a committer will take care of it.

The full text of the PR can be found at:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/134311

-- 
Edwin Groothuis via the GNATS Auto Assign Tool
edwin@FreeBSD.org
Comment 2 Edwin Groothuis freebsd_committer 2009-05-06 22:50:12 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Comment 3 Wesley Shields freebsd_committer 2009-05-06 22:56:22 UTC
Responsible Changed
From-To: freebsd-ports-bugs->wxs

I'll take it.
Comment 4 Brian Clapper 2009-05-06 23:09:12 UTC
I'm the listed maintainer of gnuls, but I do not currently have a FreeBSD 7
instance on which to test/debug this issue.
-- 
-Brian

Brian Clapper, http://www.clapper.org/bmc/
There can be no offense where none is taken.
	-- Japanese proverb
Comment 5 Timothy Beyer 2009-05-06 23:23:02 UTC
At Wed, 06 May 2009 18:09:12 -0400,
Brian Clapper wrote:
> 
> I'm the listed maintainer of gnuls, but I do not currently have a FreeBSD 7
> instance on which to test/debug this issue.
> -- 
> -Brian
> 
> Brian Clapper, http://www.clapper.org/bmc/
> There can be no offense where none is taken.
> 	-- Japanese proverb

Hi Brian,

I was talking about the version of gnuls, not FreeBSD 6.x.  I think it may also be an issue on FreeBSD 6.x, although I could be wrong...

Regards
Comment 6 Brian Clapper 2009-05-07 15:14:32 UTC
On 5/6/09 6:23 PM, Timothy Beyer wrote:
> At Wed, 06 May 2009 18:09:12 -0400,
> Brian Clapper wrote:
>> I'm the listed maintainer of gnuls, but I do not currently have a FreeBSD 7
>> instance on which to test/debug this issue.
>> -- 
>> -Brian
>>
>> Brian Clapper, http://www.clapper.org/bmc/
>> There can be no offense where none is taken.
>> 	-- Japanese proverb
> 
> Hi Brian,
> 
> I was talking about the version of gnuls, not FreeBSD 6.x.  I think it may also be an issue on FreeBSD 6.x, although I could be wrong...

Thanks. Not sure when I'll get a chance to look at this. I should really load
a more up-to-date version of FreeBSD first. The version running on my server
is embarrassingly old.
-- 
-Brian

Brian Clapper, http://www.clapper.org/bmc/
Conceit causes more conversation than wit.
	-- LaRouchefoucauld
Comment 7 Timothy Beyer 2009-05-08 09:37:22 UTC
This is a followup that I made in a private email clarifying the specific details in my report.  I apologize for not being more specific in the first place.

I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All of my filesystems are using geli.  My shell is tcsh.
 
I think I confused everyone when I was refering to 7.x, I mean the 7.x versions of gnuls, not of FreeBSD.  (and for any other version numbers that I noted, I was referring to versions of gnuls) I would suspect that any problems I'm having with gnuls would exist on any version of FreeBSD, but I'm not sure why the old Makefile revision 1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls versions 7.1 and 7.2 do not work properly fo r me.
 
Basically, the regular gnuls listing works for any of the newest port revisions, as well as the old, but the the gnuls -l does not work for the newest two port revisions.

Perhaps my problem is some incompatibility in new gnuls versions with my chosen filesystem configuration?

Regards,
Tim
Comment 8 Wesley Shields freebsd_committer 2009-06-01 18:08:29 UTC
On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> The following reply was made to PR ports/134311; it has been noted by GNATS.
> 
> From: Timothy Beyer <beyert@cs.ucr.edu>
> To: bug-followup@FreeBSD.org
> Cc: Timothy Beyer <beyert@cs.ucr.edu>
> Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> Date: Fri, 08 May 2009 01:37:22 -0700
> 
>  This is a followup that I made in a private email clarifying the
>  specific details in my report.  I apologize for not being more
>  specific in the first place.
>  
>  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
>  of my filesystems are using geli.  My shell is tcsh.
>   
>  I think I confused everyone when I was refering to 7.x, I mean the
>  7.x versions of gnuls, not of FreeBSD.  (and for any other version
>  numbers that I noted, I was referring to versions of gnuls) I would
>  suspect that any problems I'm having with gnuls would exist on any
>  version of FreeBSD, but I'm not sure why the old Makefile revision
>  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
>  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
>  versions 7.1 and 7.2 do not work properly fo r me.
>   
>  Basically, the regular gnuls listing works for any of the newest port
>  revisions, as well as the old, but the the gnuls -l does not work for
>  the newest two port revisions.
>  
>  Perhaps my problem is some incompatibility in new gnuls versions with
>  my chosen filesystem configuration?

Quite possibly this is a local problem with your configuration. I,
unfortunately don't have a solution nor the time to look into it. I'd be
happy to commit any fix Brian can come up with as the maintainer.

Brian, have you had any luck looking into this?

-- WXS
Comment 9 Brian Clapper 2009-06-01 18:16:51 UTC
On 6/1/09 1:08 PM, Wesley Shields wrote:
> On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
>> The following reply was made to PR ports/134311; it has been noted by GNATS.
>>
>> From: Timothy Beyer <beyert@cs.ucr.edu>
>> To: bug-followup@FreeBSD.org
>> Cc: Timothy Beyer <beyert@cs.ucr.edu>
>> Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
>> Date: Fri, 08 May 2009 01:37:22 -0700
>>
>>  This is a followup that I made in a private email clarifying the
>>  specific details in my report.  I apologize for not being more
>>  specific in the first place.
>>  
>>  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
>>  of my filesystems are using geli.  My shell is tcsh.
>>   
>>  I think I confused everyone when I was refering to 7.x, I mean the
>>  7.x versions of gnuls, not of FreeBSD.  (and for any other version
>>  numbers that I noted, I was referring to versions of gnuls) I would
>>  suspect that any problems I'm having with gnuls would exist on any
>>  version of FreeBSD, but I'm not sure why the old Makefile revision
>>  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
>>  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
>>  versions 7.1 and 7.2 do not work properly fo r me.
>>   
>>  Basically, the regular gnuls listing works for any of the newest port
>>  revisions, as well as the old, but the the gnuls -l does not work for
>>  the newest two port revisions.
>>  
>>  Perhaps my problem is some incompatibility in new gnuls versions with
>>  my chosen filesystem configuration?
> 
> Quite possibly this is a local problem with your configuration. I,
> unfortunately don't have a solution nor the time to look into it. I'd be
> happy to commit any fix Brian can come up with as the maintainer.
> 
> Brian, have you had any luck looking into this?

I have not, I'm afraid. I have an ancient version of FreeBSD on my server,
which I cannot upgrade at the moment. Meanwhile, my current contract has
sucked up enough of my time that I haven't had a chance to load something more
reasonable and test this stuff.
-- 
-Brian

Brian Clapper, http://www.clapper.org/bmc/
Catch a wave and you're sitting on top of the world.
Comment 10 Wesley Shields freebsd_committer 2009-06-15 20:25:01 UTC
On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> The following reply was made to PR ports/134311; it has been noted by GNATS.
> 
> From: Timothy Beyer <beyert@cs.ucr.edu>
> To: bug-followup@FreeBSD.org
> Cc: Timothy Beyer <beyert@cs.ucr.edu>
> Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> Date: Fri, 08 May 2009 01:37:22 -0700
> 
>  This is a followup that I made in a private email clarifying the
>  specific details in my report.  I apologize for not being more
>  specific in the first place.
>  
>  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
>  of my filesystems are using geli.  My shell is tcsh.
>   
>  I think I confused everyone when I was refering to 7.x, I mean the
>  7.x versions of gnuls, not of FreeBSD.  (and for any other version
>  numbers that I noted, I was referring to versions of gnuls) I would
>  suspect that any problems I'm having with gnuls would exist on any
>  version of FreeBSD, but I'm not sure why the old Makefile revision
>  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
>  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
>  versions 7.1 and 7.2 do not work properly fo r me.
>   
>  Basically, the regular gnuls listing works for any of the newest port
>  revisions, as well as the old, but the the gnuls -l does not work for
>  the newest two port revisions.
>  
>  Perhaps my problem is some incompatibility in new gnuls versions with
>  my chosen filesystem configuration?

I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested,
I don't have a machine using GELI) and I'm not sure how to proceed from
here. Can you look into using truss or ktrace to provide us with more
detailed information regarding the problem?

-- WXS
Comment 11 Timothy Beyer 2009-06-15 21:01:59 UTC
At Mon, 15 Jun 2009 15:25:01 -0400,
Wesley Shields wrote:
> 
> On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> > The following reply was made to PR ports/134311; it has been noted by GNATS.
> > 
> > From: Timothy Beyer <beyert@cs.ucr.edu>
> > To: bug-followup@FreeBSD.org
> > Cc: Timothy Beyer <beyert@cs.ucr.edu>
> > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> > Date: Fri, 08 May 2009 01:37:22 -0700
> > 
> >  This is a followup that I made in a private email clarifying the
> >  specific details in my report.  I apologize for not being more
> >  specific in the first place.
> >  
> >  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
> >  of my filesystems are using geli.  My shell is tcsh.
> >   
> >  I think I confused everyone when I was refering to 7.x, I mean the
> >  7.x versions of gnuls, not of FreeBSD.  (and for any other version
> >  numbers that I noted, I was referring to versions of gnuls) I would
> >  suspect that any problems I'm having with gnuls would exist on any
> >  version of FreeBSD, but I'm not sure why the old Makefile revision
> >  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
> >  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
> >  versions 7.1 and 7.2 do not work properly fo r me.
> >   
> >  Basically, the regular gnuls listing works for any of the newest port
> >  revisions, as well as the old, but the the gnuls -l does not work for
> >  the newest two port revisions.
> >  
> >  Perhaps my problem is some incompatibility in new gnuls versions with
> >  my chosen filesystem configuration?
> 
> I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested,
> I don't have a machine using GELI) and I'm not sure how to proceed from
> here. Can you look into using truss or ktrace to provide us with more
> detailed information regarding the problem?
> 
> -- WXS

Hi,

I will try those tools and report my results.

Tim
Comment 12 Timothy Beyer 2009-06-15 23:09:10 UTC
At Mon, 15 Jun 2009 15:25:01 -0400,
Wesley Shields wrote:
> 
> On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> > The following reply was made to PR ports/134311; it has been noted by GNATS.
> > 
> > From: Timothy Beyer <beyert@cs.ucr.edu>
> > To: bug-followup@FreeBSD.org
> > Cc: Timothy Beyer <beyert@cs.ucr.edu>
> > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> > Date: Fri, 08 May 2009 01:37:22 -0700
> > 
> >  This is a followup that I made in a private email clarifying the
> >  specific details in my report.  I apologize for not being more
> >  specific in the first place.
> >  
> >  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
> >  of my filesystems are using geli.  My shell is tcsh.
> >   
> >  I think I confused everyone when I was refering to 7.x, I mean the
> >  7.x versions of gnuls, not of FreeBSD.  (and for any other version
> >  numbers that I noted, I was referring to versions of gnuls) I would
> >  suspect that any problems I'm having with gnuls would exist on any
> >  version of FreeBSD, but I'm not sure why the old Makefile revision
> >  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
> >  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
> >  versions 7.1 and 7.2 do not work properly fo r me.
> >   
> >  Basically, the regular gnuls listing works for any of the newest port
> >  revisions, as well as the old, but the the gnuls -l does not work for
> >  the newest two port revisions.
> >  
> >  Perhaps my problem is some incompatibility in new gnuls versions with
> >  my chosen filesystem configuration?
> 
> I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested,
> I don't have a machine using GELI) and I'm not sure how to proceed from
> here. Can you look into using truss or ktrace to provide us with more
> detailed information regarding the problem?
> 
> -- WXS

Here is the output of truss and gnuls -l on /usr/local/bin.  Note that doesn't do anything after __acl_get_file calls.

[beyert@aeonserv.aeonnet] > cd /usr/local/bin/
                                                                                             [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l
__sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0)
mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
munmap(0x33c94000,296)                           = 0 (0x0)
__sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0)
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0)
open("/etc/libmap.conf",O_RDONLY,0666)           = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0)
read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6)
read(3,0x33c98000,4096)                          = 0 (0x0)
close(3)                                         = 0 (0x0)
open("/var/run/ld-elf.so.hints",O_RDONLY,00)     = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80)
mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000)
lseek(3,0x80,SEEK_SET)                           = 128 (0x80)
read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278)
close(3)                                         = 0 (0x0)
access("/lib/libc.so.7",0)                       = 0 (0x0)
open("/lib/libc.so.7",O_RDONLY,00)               = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0)
read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000)
mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC)    = 0 (0x0)
mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000)
mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000)
close(3)                                         = 0 (0x0)
sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0)
mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
munmap(0x33da7000,872)                           = 0 (0x0)
mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
munmap(0x33da7000,21176)                         = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
__sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0)
__sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0)
__sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0)
__sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0)
readlink("/etc/malloc.conf",0xbfbfe057,1024)     ERR#2 'No such file or directory'
issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0)
break(0x8100000)                                 = 0 (0x0)
__sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0)
mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000)
munmap(0x33da7000,364544)                        = 0 (0x0)
read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000)
read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222)
close(3)                                         = 0 (0x0)
open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
lseek(3,0x0,SEEK_CUR)                            = 0 (0x0)
lseek(3,0x0,SEEK_SET)                            = 0 (0x0)
read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000)
read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000)
read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000)
read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000)
read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000)
read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000)
read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000)
read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000)
read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964)
close(3)                                         = 0 (0x0)
open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0)
read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22)
close(3)                                         = 0 (0x0)
open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0)
read(3,".\n,\n3;3\n",8)                          = 8 (0x8)
close(3)                                         = 0 (0x0)
open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0)
read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179)
close(3)                                         = 0 (0x0)
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0)
read(3,"^[yYsS].*\n^[nN].*\n",18)                = 18 (0x12)
close(3)                                         = 0 (0x0)
ioctl(1,TIOCGETA,0xbfbfea38)                     = 0 (0x0)
ioctl(1,TIOCGWINSZ,0xbfbfeaa8)                   = 0 (0x0)
stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
open(".",O_NONBLOCK,06)                          = 3 (0x3)
fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
fcntl(3,F_SETFD,FD_CLOEXEC)                      = 0 (0x0)
fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14)   = 0 (0x0)
getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000)
lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0)
__acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0)
__acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0)
Comment 13 Wesley Shields freebsd_committer 2009-06-16 02:36:14 UTC
On Mon, Jun 15, 2009 at 03:09:10PM -0700, Timothy Beyer wrote:
> At Mon, 15 Jun 2009 15:25:01 -0400,
> Wesley Shields wrote:
> > 
> > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> > > The following reply was made to PR ports/134311; it has been noted by GNATS.
> > > 
> > > From: Timothy Beyer <beyert@cs.ucr.edu>
> > > To: bug-followup@FreeBSD.org
> > > Cc: Timothy Beyer <beyert@cs.ucr.edu>
> > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> > > Date: Fri, 08 May 2009 01:37:22 -0700
> > > 
> > >  This is a followup that I made in a private email clarifying the
> > >  specific details in my report.  I apologize for not being more
> > >  specific in the first place.
> > >  
> > >  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
> > >  of my filesystems are using geli.  My shell is tcsh.
> > >   
> > >  I think I confused everyone when I was refering to 7.x, I mean the
> > >  7.x versions of gnuls, not of FreeBSD.  (and for any other version
> > >  numbers that I noted, I was referring to versions of gnuls) I would
> > >  suspect that any problems I'm having with gnuls would exist on any
> > >  version of FreeBSD, but I'm not sure why the old Makefile revision
> > >  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
> > >  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
> > >  versions 7.1 and 7.2 do not work properly fo r me.
> > >   
> > >  Basically, the regular gnuls listing works for any of the newest port
> > >  revisions, as well as the old, but the the gnuls -l does not work for
> > >  the newest two port revisions.
> > >  
> > >  Perhaps my problem is some incompatibility in new gnuls versions with
> > >  my chosen filesystem configuration?
> > 
> > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested,
> > I don't have a machine using GELI) and I'm not sure how to proceed from
> > here. Can you look into using truss or ktrace to provide us with more
> > detailed information regarding the problem?
> > 
> > -- WXS
> 
> Here is the output of truss and gnuls -l on /usr/local/bin.  Note that doesn't do anything after __acl_get_file calls.
> 
> [beyert@aeonserv.aeonnet] > cd /usr/local/bin/
>                                                                                              [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l
> __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0)
> mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
> munmap(0x33c94000,296)                           = 0 (0x0)
> __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0)
> mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
> issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0)
> open("/etc/libmap.conf",O_RDONLY,0666)           = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0)
> read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6)
> read(3,0x33c98000,4096)                          = 0 (0x0)
> close(3)                                         = 0 (0x0)
> open("/var/run/ld-elf.so.hints",O_RDONLY,00)     = 3 (0x3)
> read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80)
> mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000)
> lseek(3,0x80,SEEK_SET)                           = 128 (0x80)
> read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278)
> close(3)                                         = 0 (0x0)
> access("/lib/libc.so.7",0)                       = 0 (0x0)
> open("/lib/libc.so.7",O_RDONLY,00)               = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0)
> read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
> mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000)
> mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
> mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC)    = 0 (0x0)
> mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000)
> mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000)
> close(3)                                         = 0 (0x0)
> sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0)
> mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> munmap(0x33da7000,872)                           = 0 (0x0)
> mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> munmap(0x33da7000,21176)                         = 0 (0x0)
> sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
> sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
> __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0)
> sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
> sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
> open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0)
> __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0)
> __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0)
> __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0)
> readlink("/etc/malloc.conf",0xbfbfe057,1024)     ERR#2 'No such file or directory'
> issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0)
> break(0x8100000)                                 = 0 (0x0)
> __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0)
> mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000)
> munmap(0x33da7000,364544)                        = 0 (0x0)
> read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000)
> read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222)
> close(3)                                         = 0 (0x0)
> open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
> fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
> lseek(3,0x0,SEEK_CUR)                            = 0 (0x0)
> lseek(3,0x0,SEEK_SET)                            = 0 (0x0)
> read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000)
> read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000)
> read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000)
> read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000)
> read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000)
> read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000)
> read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000)
> read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000)
> read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964)
> close(3)                                         = 0 (0x0)
> open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0)
> read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22)
> close(3)                                         = 0 (0x0)
> open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0)
> read(3,".\n,\n3;3\n",8)                          = 8 (0x8)
> close(3)                                         = 0 (0x0)
> open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0)
> read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179)
> close(3)                                         = 0 (0x0)
> open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0)
> read(3,"^[yYsS].*\n^[nN].*\n",18)                = 18 (0x12)
> close(3)                                         = 0 (0x0)
> ioctl(1,TIOCGETA,0xbfbfea38)                     = 0 (0x0)
> ioctl(1,TIOCGWINSZ,0xbfbfeaa8)                   = 0 (0x0)
> stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
> open(".",O_NONBLOCK,06)                          = 3 (0x3)
> fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
> fcntl(3,F_SETFD,FD_CLOEXEC)                      = 0 (0x0)
> fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14)   = 0 (0x0)
> getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000)
> lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0)
> __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0)
> __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0)

Does this happen on every directory or just this particular one? Can you
give me the output of ls -l for any particular directory which causes
the problem and any ACLs set in there?

Thanks!

-- WXS
Comment 14 Timothy Beyer 2009-06-16 20:10:42 UTC
At Mon, 15 Jun 2009 21:36:14 -0400,
Wesley Shields wrote:
> 
> On Mon, Jun 15, 2009 at 03:09:10PM -0700, Timothy Beyer wrote:
> > At Mon, 15 Jun 2009 15:25:01 -0400,
> > Wesley Shields wrote:
> > > 
> > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> > > > The following reply was made to PR ports/134311; it has been noted by GNATS.
> > > > 
> > > > From: Timothy Beyer <beyert@cs.ucr.edu>
> > > > To: bug-followup@FreeBSD.org
> > > > Cc: Timothy Beyer <beyert@cs.ucr.edu>
> > > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> > > > Date: Fri, 08 May 2009 01:37:22 -0700
> > > > 
> > > >  This is a followup that I made in a private email clarifying the
> > > >  specific details in my report.  I apologize for not being more
> > > >  specific in the first place.
> > > >  
> > > >  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
> > > >  of my filesystems are using geli.  My shell is tcsh.
> > > >   
> > > >  I think I confused everyone when I was refering to 7.x, I mean the
> > > >  7.x versions of gnuls, not of FreeBSD.  (and for any other version
> > > >  numbers that I noted, I was referring to versions of gnuls) I would
> > > >  suspect that any problems I'm having with gnuls would exist on any
> > > >  version of FreeBSD, but I'm not sure why the old Makefile revision
> > > >  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
> > > >  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
> > > >  versions 7.1 and 7.2 do not work properly fo r me.
> > > >   
> > > >  Basically, the regular gnuls listing works for any of the newest port
> > > >  revisions, as well as the old, but the the gnuls -l does not work for
> > > >  the newest two port revisions.
> > > >  
> > > >  Perhaps my problem is some incompatibility in new gnuls versions with
> > > >  my chosen filesystem configuration?
> > > 
> > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested,
> > > I don't have a machine using GELI) and I'm not sure how to proceed from
> > > here. Can you look into using truss or ktrace to provide us with more
> > > detailed information regarding the problem?
> > > 
> > > -- WXS
> > 
> > Here is the output of truss and gnuls -l on /usr/local/bin.  Note that doesn't do anything after __acl_get_file calls.
> > 
> > [beyert@aeonserv.aeonnet] > cd /usr/local/bin/
> >                                                                                              [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l
> > __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0)
> > mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
> > munmap(0x33c94000,296)                           = 0 (0x0)
> > __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0)
> > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
> > issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0)
> > open("/etc/libmap.conf",O_RDONLY,0666)           = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0)
> > read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6)
> > read(3,0x33c98000,4096)                          = 0 (0x0)
> > close(3)                                         = 0 (0x0)
> > open("/var/run/ld-elf.so.hints",O_RDONLY,00)     = 3 (0x3)
> > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80)
> > mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000)
> > lseek(3,0x80,SEEK_SET)                           = 128 (0x80)
> > read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278)
> > close(3)                                         = 0 (0x0)
> > access("/lib/libc.so.7",0)                       = 0 (0x0)
> > open("/lib/libc.so.7",O_RDONLY,00)               = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0)
> > read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
> > mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000)
> > mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
> > mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC)    = 0 (0x0)
> > mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000)
> > mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000)
> > close(3)                                         = 0 (0x0)
> > sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0)
> > mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> > munmap(0x33da7000,872)                           = 0 (0x0)
> > mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> > munmap(0x33da7000,21176)                         = 0 (0x0)
> > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
> > sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
> > __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0)
> > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
> > sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0)
> > __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0)
> > __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0)
> > __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0)
> > readlink("/etc/malloc.conf",0xbfbfe057,1024)     ERR#2 'No such file or directory'
> > issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0)
> > break(0x8100000)                                 = 0 (0x0)
> > __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0)
> > mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> > mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000)
> > munmap(0x33da7000,364544)                        = 0 (0x0)
> > read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000)
> > read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
> > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
> > lseek(3,0x0,SEEK_CUR)                            = 0 (0x0)
> > lseek(3,0x0,SEEK_SET)                            = 0 (0x0)
> > read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000)
> > read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000)
> > read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000)
> > read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000)
> > read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000)
> > read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000)
> > read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0)
> > read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0)
> > read(3,".\n,\n3;3\n",8)                          = 8 (0x8)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0)
> > read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0)
> > read(3,"^[yYsS].*\n^[nN].*\n",18)                = 18 (0x12)
> > close(3)                                         = 0 (0x0)
> > ioctl(1,TIOCGETA,0xbfbfea38)                     = 0 (0x0)
> > ioctl(1,TIOCGWINSZ,0xbfbfeaa8)                   = 0 (0x0)
> > stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
> > open(".",O_NONBLOCK,06)                          = 3 (0x3)
> > fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
> > fcntl(3,F_SETFD,FD_CLOEXEC)                      = 0 (0x0)
> > fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14)   = 0 (0x0)
> > getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000)
> > lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0)
> > __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0)
> > __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0)
> 
> Does this happen on every directory or just this particular one? Can you
> give me the output of ls -l for any particular directory which causes
> the problem and any ACLs set in there?
> 
> Thanks!
> 
> -- WXS

Hi,

Thus far, it doesn't terminate on any directory that I have tried.  (/var ,/tmp /external, /proc, /root, ~/, /usr/local/bin, /usr/bin, and dozens of other directories that don't actually use ACLs, among many of which are deep subdirectories on a filesystem)

For what it's worth, I've never actually used ACLs on any file on my computer, I merely enabled ACLs on all of my filesystems.

All of the outputs of truss mentioned above end with something like the following: (the first hexidecimal number varies based on directory and if current working directory is used instead of directly specifying the path)
__acl_get_file(0xbfbfebd9,0x0,0x33e0c240,0xbfbfebd9,0x33e12008,0x33e12000) = 0 (0x0)
__acl_get_file(0xbfbfebd9,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0)

None terminate, except when a non-existent directory is given as a parameter. (but then it gives a "No such file or directory" error as it should)

Tim
Comment 15 Timothy Beyer 2009-06-16 20:23:50 UTC
At Mon, 15 Jun 2009 21:36:14 -0400,
Wesley Shields wrote:
> 
> On Mon, Jun 15, 2009 at 03:09:10PM -0700, Timothy Beyer wrote:
> > At Mon, 15 Jun 2009 15:25:01 -0400,
> > Wesley Shields wrote:
> > > 
> > > On Fri, May 08, 2009 at 08:40:02AM +0000, Timothy Beyer wrote:
> > > > The following reply was made to PR ports/134311; it has been noted by GNATS.
> > > > 
> > > > From: Timothy Beyer <beyert@cs.ucr.edu>
> > > > To: bug-followup@FreeBSD.org
> > > > Cc: Timothy Beyer <beyert@cs.ucr.edu>
> > > > Subject: Re: ports/134311: misc/gnuls: problems with gnuls -l on versions	&gt;= 7.x
> > > > Date: Fri, 08 May 2009 01:37:22 -0700
> > > > 
> > > >  This is a followup that I made in a private email clarifying the
> > > >  specific details in my report.  I apologize for not being more
> > > >  specific in the first place.
> > > >  
> > > >  I'm using UFS2 with softupdates on my filesystem, ACLs enabled.  All
> > > >  of my filesystems are using geli.  My shell is tcsh.
> > > >   
> > > >  I think I confused everyone when I was refering to 7.x, I mean the
> > > >  7.x versions of gnuls, not of FreeBSD.  (and for any other version
> > > >  numbers that I noted, I was referring to versions of gnuls) I would
> > > >  suspect that any problems I'm having with gnuls would exist on any
> > > >  version of FreeBSD, but I'm not sure why the old Makefile revision
> > > >  1.23 / gnuls version 6.12 (2009 Jan 13) works properly for me, but
> > > >  the revisions 1.24 (2009 Feb 23) and 1.25 (2009 Apr 21) / gnuls
> > > >  versions 7.1 and 7.2 do not work properly fo r me.
> > > >   
> > > >  Basically, the regular gnuls listing works for any of the newest port
> > > >  revisions, as well as the old, but the the gnuls -l does not work for
> > > >  the newest two port revisions.
> > > >  
> > > >  Perhaps my problem is some incompatibility in new gnuls versions with
> > > >  my chosen filesystem configuration?
> > > 
> > > I can't reproduce this anywhere (UFS2 + softupdates and ZFS were tested,
> > > I don't have a machine using GELI) and I'm not sure how to proceed from
> > > here. Can you look into using truss or ktrace to provide us with more
> > > detailed information regarding the problem?
> > > 
> > > -- WXS
> > 
> > Here is the output of truss and gnuls -l on /usr/local/bin.  Note that doesn't do anything after __acl_get_file calls.
> > 
> > [beyert@aeonserv.aeonnet] > cd /usr/local/bin/
> >                                                                                              [beyert@aeonserv.aeonnet] > sudo truss /usr/local/bin/gnuls -l
> > __sysctl(0xbfbfe864,0x2,0xbfbfe86c,0xbfbfe870,0x0,0x0) = 0 (0x0)
> > mmap(0x0,296,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
> > munmap(0x33c94000,296)                           = 0 (0x0)
> > __sysctl(0xbfbfe8c8,0x2,0x33c90e5c,0xbfbfe8d0,0x0,0x0) = 0 (0x0)
> > mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868827136 (0x33c94000)
> > issetugid(0x33c89f8c,0xbfbfe990,0x104,0x0,0x0,0x0) = 0 (0x0)
> > open("/etc/libmap.conf",O_RDONLY,0666)           = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=24791,size=3766,blksize=4096 }) = 0 (0x0)
> > read(3,"# /etc/libmap.conf for FreeBSD 6"...,4096) = 3766 (0xeb6)
> > read(3,0x33c98000,4096)                          = 0 (0x0)
> > close(3)                                         = 0 (0x0)
> > open("/var/run/ld-elf.so.hints",O_RDONLY,00)     = 3 (0x3)
> > read(3,"Ehnt\^A\0\0\0\M^@\0\0\0x\^B\0\0"...,128) = 128 (0x80)
> > mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 868859904 (0x33c9c000)
> > lseek(3,0x80,SEEK_SET)                           = 128 (0x80)
> > read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,632) = 632 (0x278)
> > close(3)                                         = 0 (0x0)
> > access("/lib/libc.so.7",0)                       = 0 (0x0)
> > open("/lib/libc.so.7",O_RDONLY,00)               = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=16584,size=1058208,blksize=4096 }) = 0 (0x0)
> > read(3,"\^?ELF\^A\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
> > mmap(0x0,1056768,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 868896768 (0x33ca5000)
> > mprotect(0x33d8c000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
> > mprotect(0x33d8c000,4096,PROT_READ|PROT_EXEC)    = 0 (0x0)
> > mmap(0x33d8d000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xe8000) = 869847040 (0x33d8d000)
> > mmap(0x33d93000,81920,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 869871616 (0x33d93000)
> > close(3)                                         = 0 (0x0)
> > sysarch(0xa,0xbfbfe930,0x33c6a21b,0x33c8f814,0x33c7b619,0x33c8f814) = 0 (0x0)
> > mmap(0x0,872,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> > munmap(0x33da7000,872)                           = 0 (0x0)
> > mmap(0x0,21176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> > munmap(0x33da7000,21176)                         = 0 (0x0)
> > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
> > sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
> > __sysctl(0xbfbfe8e4,0x2,0x33d93ae0,0xbfbfe8ec,0x0,0x0) = 0 (0x0)
> > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
> > sigprocmask(SIG_SETMASK,0x0,0x0)                 = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_COLLATE",O_RDONLY,0666) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=950042,size=4642,blksize=4096 }) = 0 (0x0)
> > __sysctl(0xbfbfe458,0x2,0x33d978c0,0xbfbfe464,0x0,0x0) = 0 (0x0)
> > __sysctl(0xbfbfdf68,0x2,0x33da405c,0xbfbfdf70,0x0,0x0) = 0 (0x0)
> > __sysctl(0xbfbfdfb8,0x2,0xbfbfdfc4,0xbfbfdfc8,0x0,0x0) = 0 (0x0)
> > readlink("/etc/malloc.conf",0xbfbfe057,1024)     ERR#2 'No such file or directory'
> > issetugid(0x33d84ec0,0xbfbfe057,0x400,0xbfbfe464,0x0,0x0) = 0 (0x0)
> > break(0x8100000)                                 = 0 (0x0)
> > __sysctl(0xbfbfe2d4,0x2,0xbfbfe2dc,0xbfbfe2e0,0x0,0x0) = 0 (0x0)
> > mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 869953536 (0x33da7000)
> > mmap(0x33ea7000,364544,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 871002112 (0x33ea7000)
> > munmap(0x33da7000,364544)                        = 0 (0x0)
> > read(3,"1.2\n\0\0\0\0\0\0\0\0\0\^A\0\0\0"...,4096) = 4096 (0x1000)
> > read(3,"\0\M-?\0\0\0\0\0\0\0\M-@\0\0\0\0"...,4096) = 546 (0x222)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_CTYPE",O_RDONLY,0666) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
> > fstat(3,{ mode=-r--r--r-- ,inode=971562,size=76132,blksize=4096 }) = 0 (0x0)
> > lseek(3,0x0,SEEK_CUR)                            = 0 (0x0)
> > lseek(3,0x0,SEEK_SET)                            = 0 (0x0)
> > read(3,"RuneMag1UTF-8\0\0\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0\0\0\n\M-<\0\0\n\M-E@\^D"...,4096) = 4096 (0x1000)
> > read(3,"\0\0\^AJ\0\0\^AJ\0\0\^AK\0\0\^AL"...,4096) = 4096 (0x1000)
> > read(3,"\0\0\^_\^O\0\0\^_\0\0\0\^_\^X\0"...,4096) = 4096 (0x1000)
> > read(3,"\0\0\^^T\0\0\^^W\0\0\^^W\0\0\^^V"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\M^I\0@\^D\^Y\0@\^D\M^I\0@"...,4096) = 4096 (0x1000)
> > read(3,"@$\b\0@$\b\0@$\b\0@$\b\0@$\b\0@$"...,4096) = 4096 (0x1000)
> > read(3,"@\^D(\0@\^D(\0@\^D(\0@\^D(\0@\^D"...,4096) = 4096 (0x1000)
> > read(3,"\M^@$\b\0\M^@$\b\0\M^@$\b\0\M^@$"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\0\0@\^D\0\0@\^D\0\0@\^D\0\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\b\0@\^D\b\0@\^D\b\0@\^D\b\0"...,4096) = 4096 (0x1000)
> > read(3,"@\^D\M^I\0@\^D\M^I\0@\^D\M^I\0@"...,4096) = 2404 (0x964)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_MONETARY",O_RDONLY,06370000000) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=974091,size=34,blksize=4096 }) = 0 (0x0)
> > read(3,"USD \n$\n.\n,\n3;3\n\n-\n2\n2\n1"...,34) = 34 (0x22)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_NUMERIC",O_RDONLY,042) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=975978,size=8,blksize=4096 }) = 0 (0x0)
> > read(3,".\n,\n3;3\n",8)                          = 8 (0x8)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_TIME",O_RDONLY,010) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=976068,size=377,blksize=4096 }) = 0 (0x0)
> > read(3,"Jan\nFeb\nMar\nApr\nMay\nJun\nJu"...,377) = 377 (0x179)
> > close(3)                                         = 0 (0x0)
> > open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES",O_RDONLY,0571) = 3 (0x3)
> > fstat(3,{ mode=-r--r--r-- ,inode=975871,size=18,blksize=4096 }) = 0 (0x0)
> > read(3,"^[yYsS].*\n^[nN].*\n",18)                = 18 (0x12)
> > close(3)                                         = 0 (0x0)
> > ioctl(1,TIOCGETA,0xbfbfea38)                     = 0 (0x0)
> > ioctl(1,TIOCGWINSZ,0xbfbfeaa8)                   = 0 (0x0)
> > stat(".",{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
> > open(".",O_NONBLOCK,06)                          = 3 (0x3)
> > fstat(3,{ mode=drwxr-xr-x ,inode=927744,size=81408,blksize=4096 }) = 0 (0x0)
> > fcntl(3,F_SETFD,FD_CLOEXEC)                      = 0 (0x0)
> > fstatfs(0x3,0xbfbfe6a4,0x1,0x2,0x1,0x33c8fe14)   = 0 (0x0)
> > getdirentries(0x3,0x33e18000,0x1000,0x33e010e4,0x0,0x33c96200) = 4096 (0x1000)
> > lstat("lua50",{ mode=drwxr-xr-x ,inode=927745,size=512,blksize=4096 }) = 0 (0x0)
> > __acl_get_file(0xbfbfe770,0x0,0x33e0c240,0xbfbfe770,0x33e12008,0x33e12000) = 0 (0x0)
> > __acl_get_file(0xbfbfe770,0x1,0x33e0c240,0x33cfcb81,0x2d,0x33e0c240) = 0 (0x0)
> 
> Does this happen on every directory or just this particular one? Can you
> give me the output of ls -l for any particular directory which causes
> the problem and any ACLs set in there?
> 
> Thanks!
> 
> -- WXS

To add to my previous comment:

Having tried it on /usr/bin right now, when the directory is not given as a parameter, it terminates properly.  That is the only directory that works properly, thus far.

Tim
Comment 16 Wesley Shields freebsd_committer 2009-06-22 15:10:47 UTC
On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote:
>  To add to my previous comment:
>  
>  Having tried it on /usr/bin right now, when the directory is not
>  given as a parameter, it terminates properly.  That is the only
>  directory that works properly, thus far.

I've just now been able to reproduce this problem. I completely forgot
that I wasn't mounting my test volume with the acls option. Sorry about
that.

I've also noticed that there are newer versions of gnuls released since
then. The latest (7.4) appears to solve this problem. I've attached a
patch to update the port and would like Brian's approval to commit it.

To satisfy my own curiosity, what is the reason for using gnuls over the
base ls? Is there some option the base one does not provide?

-- WXS
Comment 17 Brian Clapper 2009-06-22 15:23:14 UTC
On 6/22/09 10:10 AM, Wesley Shields wrote:
> On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote:
>>  To add to my previous comment:
>>  
>>  Having tried it on /usr/bin right now, when the directory is not
>>  given as a parameter, it terminates properly.  That is the only
>>  directory that works properly, thus far.
> 
> I've just now been able to reproduce this problem. I completely forgot
> that I wasn't mounting my test volume with the acls option. Sorry about
> that.
> 
> I've also noticed that there are newer versions of gnuls released since
> then. The latest (7.4) appears to solve this problem. I've attached a
> patch to update the port and would like Brian's approval to commit it.
> 
> To satisfy my own curiosity, what is the reason for using gnuls over the
> base ls? Is there some option the base one does not provide?

I created the gnuls port years ago (more than a decade), when I started using
FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in
particular, its specific way of configuring colorization. I wanted consistency
between Linux and FreeBSD, so I created a port. That's really the only reason
the port exists at all.
-- 
-Brian

Brian Clapper, http://www.clapper.org/bmc/
Life is a whim of several billion cells to be you for a while.
Comment 18 Wesley Shields freebsd_committer 2009-06-22 15:26:20 UTC
On Mon, Jun 22, 2009 at 10:23:14AM -0400, Brian Clapper wrote:
> On 6/22/09 10:10 AM, Wesley Shields wrote:
> > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote:
> >>  To add to my previous comment:
> >>  
> >>  Having tried it on /usr/bin right now, when the directory is not
> >>  given as a parameter, it terminates properly.  That is the only
> >>  directory that works properly, thus far.
> > 
> > I've just now been able to reproduce this problem. I completely forgot
> > that I wasn't mounting my test volume with the acls option. Sorry about
> > that.
> > 
> > I've also noticed that there are newer versions of gnuls released since
> > then. The latest (7.4) appears to solve this problem. I've attached a
> > patch to update the port and would like Brian's approval to commit it.
> > 
> > To satisfy my own curiosity, what is the reason for using gnuls over the
> > base ls? Is there some option the base one does not provide?
> 
> I created the gnuls port years ago (more than a decade), when I started using
> FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in
> particular, its specific way of configuring colorization. I wanted consistency
> between Linux and FreeBSD, so I created a port. That's really the only reason
> the port exists at all.

Fair enough. I'm not questioning the existence of the port, but am
mostly interested in why Timothy was using it specifically. If there is
a glaringly obvious deficiency in our ls we may want to address that.

In any case, the patch appears to fix the problem by updating to a new
version. Can you approve it?

-- WXS
Comment 19 dfilter service freebsd_committer 2009-06-22 15:49:59 UTC
wxs         2009-06-22 14:49:51 UTC

  FreeBSD ports repository

  Modified files:
    misc/gnuls           Makefile distinfo 
  Log:
  - Update to 7.4 which should solve the ACL issue.
  
  PR:             ports/134311
  Submitted by:   Timothy Beyer <beyert@cs.ucr.edu>
  Approved by:    Brian Clapper <bmc@clapper.org> (maintainer)
  
  Revision  Changes    Path
  1.26      +1 -1      ports/misc/gnuls/Makefile
  1.12      +3 -3      ports/misc/gnuls/distinfo
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 20 Wesley Shields freebsd_committer 2009-06-22 15:50:11 UTC
State Changed
From-To: feedback->closed

Updated to 7.4 which solves this problem. Thanks for your patience!
Comment 21 Timothy Beyer 2009-06-22 19:44:29 UTC
At Mon, 22 Jun 2009 10:10:47 -0400,
Wesley Shields wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote:
> >  To add to my previous comment:
> >  
> >  Having tried it on /usr/bin right now, when the directory is not
> >  given as a parameter, it terminates properly.  That is the only
> >  directory that works properly, thus far.
> 
> I've just now been able to reproduce this problem. I completely forgot
> that I wasn't mounting my test volume with the acls option. Sorry about
> that.
> 
> I've also noticed that there are newer versions of gnuls released since
> then. The latest (7.4) appears to solve this problem. I've attached a
> patch to update the port and would like Brian's approval to commit it.
> 
> To satisfy my own curiosity, what is the reason for using gnuls over the
> base ls? Is there some option the base one does not provide?
> 
> -- WXS

Oh,

The only reason why I cared about gnuls at all was because dired, at least in XEmacs only works with it, you have to modify the regular expressions to get bsd ls working.

However, I wrote my only replacement for dired which uses my own "ls" program, as well as bsd ls, so it is no longer an issue.  I just thought that it would be nice to report the problem.

I actually don't use gnuls at all anymore, since bsd ls has all the same features, approximately the same performance profile, and a better license.

Tim
Comment 22 Timothy Beyer 2009-06-22 19:48:50 UTC
At Mon, 22 Jun 2009 10:26:20 -0400,
Wesley Shields wrote:
> 
> On Mon, Jun 22, 2009 at 10:23:14AM -0400, Brian Clapper wrote:
> > On 6/22/09 10:10 AM, Wesley Shields wrote:
> > > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote:
> > >>  To add to my previous comment:
> > >>  
> > >>  Having tried it on /usr/bin right now, when the directory is not
> > >>  given as a parameter, it terminates properly.  That is the only
> > >>  directory that works properly, thus far.
> > > 
> > > I've just now been able to reproduce this problem. I completely forgot
> > > that I wasn't mounting my test volume with the acls option. Sorry about
> > > that.
> > > 
> > > I've also noticed that there are newer versions of gnuls released since
> > > then. The latest (7.4) appears to solve this problem. I've attached a
> > > patch to update the port and would like Brian's approval to commit it.
> > > 
> > > To satisfy my own curiosity, what is the reason for using gnuls over the
> > > base ls? Is there some option the base one does not provide?
> > 
> > I created the gnuls port years ago (more than a decade), when I started using
> > FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in
> > particular, its specific way of configuring colorization. I wanted consistency
> > between Linux and FreeBSD, so I created a port. That's really the only reason
> > the port exists at all.
> 
> Fair enough. I'm not questioning the existence of the port, but am
> mostly interested in why Timothy was using it specifically. If there is
> a glaringly obvious deficiency in our ls we may want to address that.
> 
No deficiencies, although it would be nice to have more control over the way dates are formatted in bsd ls.  The performance of the both is generally so good that I don't think that performance is a compelling advantage for gnuls.  For what it's worth, I no longer use gnuls.  (see my other response)

> In any case, the patch appears to fix the problem by updating to a new
> version. Can you approve it?
> 
> -- WXS
Comment 23 Timothy Beyer 2009-06-22 19:52:59 UTC
At Mon, 22 Jun 2009 10:26:20 -0400,
Wesley Shields wrote:
> 
> On Mon, Jun 22, 2009 at 10:23:14AM -0400, Brian Clapper wrote:
> > On 6/22/09 10:10 AM, Wesley Shields wrote:
> > > On Tue, Jun 16, 2009 at 07:30:03PM +0000, Timothy Beyer wrote:
> > >>  To add to my previous comment:
> > >>  
> > >>  Having tried it on /usr/bin right now, when the directory is not
> > >>  given as a parameter, it terminates properly.  That is the only
> > >>  directory that works properly, thus far.
> > > 
> > > I've just now been able to reproduce this problem. I completely forgot
> > > that I wasn't mounting my test volume with the acls option. Sorry about
> > > that.
> > > 
> > > I've also noticed that there are newer versions of gnuls released since
> > > then. The latest (7.4) appears to solve this problem. I've attached a
> > > patch to update the port and would like Brian's approval to commit it.
> > > 
> > > To satisfy my own curiosity, what is the reason for using gnuls over the
> > > base ls? Is there some option the base one does not provide?
> > 
> > I created the gnuls port years ago (more than a decade), when I started using
> > FreeBSD. I'd already been using Linux. I was accustomed to GNU ls on Linux--in
> > particular, its specific way of configuring colorization. I wanted consistency
> > between Linux and FreeBSD, so I created a port. That's really the only reason
> > the port exists at all.
> 
> Fair enough. I'm not questioning the existence of the port, but am
> mostly interested in why Timothy was using it specifically. If there is
> a glaringly obvious deficiency in our ls we may want to address that.
> 
> In any case, the patch appears to fix the problem by updating to a new
> version. Can you approve it?
> 
> -- WXS

Also, thanks for the effort you and Brian have put into this, I am glad to see a solution to the problem in sight.  Mostly because if gnuls isn't working properly, it might turn off Linux users from FreeBSD, more than anything else.

Tim