# ls -l, *
/usr/main-src/lib/libc/stdio/fread.c:133:10: runtime error: applying zero
offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/main-src/lib/libc/stdio/fread.c:133:10 in
==47404==AddressSanitizer: WARNING: unexpected format specifier in printf
Hello,
I just submitted two differentials, D30545 and D30547, for color
support in diff(1) and underline support in ls(1) respectively. While I
was submitting these I also noticed that .arcconfig is still configured
to submit differentials to the subversion repo, not the git one
On 09.04.2017 19:31, Nilton José Rizzo wrote:
>try this
>
> ls [a-b,k-m]
>
>in sh using the locale setting to pt_BR.UTF-8
>
> it's not work
For the set below I got on -current
a A b k K l m
with any non-C loca
Em 2017-04-09 00:26, Andrey Chernov escreveu:
On 07.04.2017 23:20, Nilton José Rizzo wrote:
Em 2017-04-07 05:51, Toomas Soome escreveu:
On 7. apr 2017, at 11:29, Andrey Chernov wrote:
Hi Allan, the ls show all files without case match
ls [a-z]*
show all files beginning with a and A like
On 07.04.2017 23:20, Nilton José Rizzo wrote:
> Em 2017-04-07 05:51, Toomas Soome escreveu:
>>> On 7. apr 2017, at 11:29, Andrey Chernov wrote:
>>>
>>>> Hi Allan, the ls show all files without case match
>>>>
>>>> ls [a-z]*
>>
Em 2017-04-07 05:51, Toomas Soome escreveu:
On 7. apr 2017, at 11:29, Andrey Chernov wrote:
Hi Allan, the ls show all files without case match
ls [a-z]*
show all files beginning with a and A like this [aA-zZ]*
No, last "Z" is not included.
Look this, it'
In article <3a8b8ade882d1486aa41b448a9c83...@i805.com.br> you write:
>
>
> It's a terrible Is it a locale bug? Look!
>
>% locale
>LANG=pt_BR.UTF-8
>% touch E
>% ls -l [a-z]*
>-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 E
No, it's the specifica
On 07.04.2017 11:51, Toomas Soome wrote:
>
>> On 7. apr 2017, at 11:29, Andrey Chernov wrote:
>>
>>> Hi Allan, the ls show all files without case match
>>>
>>> ls [a-z]*
>>>
>>> show all files beginning with a and A like this [aA
> On 7. apr 2017, at 11:29, Andrey Chernov wrote:
>
>> Hi Allan, the ls show all files without case match
>>
>> ls [a-z]*
>>
>> show all files beginning with a and A like this [aA-zZ]*
>
> No, last "Z" is not included.
>
This is to
> Hi Allan, the ls show all files without case match
>
> ls [a-z]*
>
> show all files beginning with a and A like this [aA-zZ]*
No, last "Z" is not included.
___
freebsd-current@freebsd.org mailing list
https://lists.fre
Em 2017-04-07 02:29, Garrett Wollman escreveu:
In article <3a8b8ade882d1486aa41b448a9c83...@i805.com.br> you write:
It's a terrible Is it a locale bug? Look!
% locale
LANG=pt_BR.UTF-8
% touch E
% ls -l [a-z]*
-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 E
No, it's the
> On Apr 6, 2017, at 22:15, Ngie Cooper (yaneurabeya)
> wrote:
>
>
>> On Apr 6, 2017, at 21:28, Nilton José Rizzo wrote:
>
> …
>
>> [966] root@valfenda rizzo #locale
>> LANG=pt_BR.UTF-8
>> LC_CTYPE="pt_BR.UTF-8"
>> LC_COLLATE="pt_BR.UTF-8"
>> LC_TIME="pt_BR.UTF-8"
>> LC_NUMERIC="pt_BR.UTF-8
> On Apr 6, 2017, at 21:28, Nilton José Rizzo wrote:
…
> [966] root@valfenda rizzo #locale
> LANG=pt_BR.UTF-8
> LC_CTYPE="pt_BR.UTF-8"
> LC_COLLATE="pt_BR.UTF-8"
> LC_TIME="pt_BR.UTF-8"
> LC_NUMERIC="pt_BR.UTF-8"
> LC_MONETARY="pt_BR.UTF-8"
> LC_MESSAGES="pt_BR.UTF-8"
> LC_ALL=
I bet t
C_ALL=
% pwd
/home2/rizzo/tmp/teste
% touch a
% touch b
% touch c
% touch d
% touch A
% touch D
% touch E
% ls -l [a-z]*
-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 a
-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 A
-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 b
-rw-r--r-- 1 rizzo wheel 0 7 abr 02:06 c
-rw-r-
Em 2017-04-07 01:33, Allan Jude escreveu:
On 2017-04-06 23:12, Nilton José Rizzo wrote:
Hi all
Look this command on a FreeBSD -current
% ls -d /usr/ports/[a-z]*
/usr/ports/accessibility /usr/ports/math
/usr/ports/arabic /usr/ports/misc
/usr/ports/archivers /usr/ports/Mk
/usr/ports/astro
On 2017-04-06 23:12, Nilton José Rizzo wrote:
> Hi all
>
> Look this command on a FreeBSD -current
>
> % ls -d /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/math
> /usr/ports/arabic /usr/ports/misc
> /usr/ports/archivers /usr/ports/Mk
> /usr/ports/as
Em 2017-04-07 00:59, Ngie Cooper escreveu:
On Apr 6, 2017, at 20:12, Nilton José Rizzo wrote:
Hi all
Look this command on a FreeBSD -current
% ls -d /usr/ports/[a-z]*
/usr/ports/accessibility /usr/ports/math
/usr/ports/arabic /usr/ports/misc
/usr/ports/archivers /usr/ports/Mk
/usr/ports
> On Apr 6, 2017, at 20:12, Nilton José Rizzo wrote:
>
> Hi all
>
> Look this command on a FreeBSD -current
>
> % ls -d /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/math
> /usr/ports/arabic /usr/ports/misc
> /usr/ports/archivers /usr/ports/Mk
>
Hi all
Look this command on a FreeBSD -current
% ls -d /usr/ports/[a-z]*
/usr/ports/accessibility /usr/ports/math
/usr/ports/arabic /usr/ports/misc
/usr/ports/archivers /usr/ports/Mk
/usr/ports/astro /usr/ports/MOVED
/usr/ports/audio /usr/ports/multimedia
% echo /usr/ports/[a-z]*
/usr
On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote:
> I can reproduce it on a clean 11.0-BETA1 VM.
>
fixed in r302916.
Will merge in 2 days in stable/11
Best regards,
Bapt
signature.asc
Description: PGP signature
On Sun, Jul 10, 2016 at 04:23:03PM +0800, Huang Wen Hui wrote:
> I can reproduce it on a clean 11.0-BETA1 VM.
>
>
> 2016-07-09 9:03 GMT+08:00 Huang Wen Hui :
>
> > For some reasons, r302324 seems not include in 11.0-ALPHA6?
> >
> > 2016-07-09 8:52 GMT+08:00 Huang Wen Hui :
> >
> >> Revert back r
rs
>> Huang Wen Hui
>>
>> 2016-07-05 16:50 GMT+08:00 Baptiste Daroussin :
>>
>>> On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote:
>>> > These 2 files can make ls suck:
>>> >
>>> > touch 火灾1
>>> > touch 火灾2
6:42PM +0800, Huang Wen Hui wrote:
>> > These 2 files can make ls suck:
>> >
>> > touch 火灾1
>> > touch 火灾2
>> >
>> > 2 files start with 2 same Chinese chars.
>> >
>> I cannot reproduce on my head laptop, neither o
Revert back r302324, Chinese locale problem is gone.
Cheers
Huang Wen Hui
2016-07-05 16:50 GMT+08:00 Baptiste Daroussin :
> On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote:
> > These 2 files can make ls suck:
> >
> > touch 火灾1
> > touch 火灾2
> &
On Tue, Jul 05, 2016 at 12:16:42PM +0800, Huang Wen Hui wrote:
> These 2 files can make ls suck:
>
> touch 火灾1
> touch 火灾2
>
> 2 files start with 2 same Chinese chars.
>
I cannot reproduce on my head laptop, neither on a clean 11.0-ALPHA6 jail.
I'll try on a clean 11
These 2 files can make ls suck:
touch 火灾1
touch 火灾2
2 files start with 2 same Chinese chars.
% lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) run
Process 2185 launching
Process 2185 launched: '/bin/ls' (x86_64)
E
n, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> > > > > Hi,
> > > > > On very recent CURRENT, ls can eat high CPU time when
> > LANG=zh_CN.UTF-8
> > > > and
> > > > > LC_ALL=zh_CN.UTF-8:
> > > > >
> > &g
2016-07-04 14:41 GMT+08:00 Baptiste Daroussin :
> On Mon, Jul 04, 2016 at 02:36:11PM +0800, Huang Wen Hui wrote:
> > 2016-07-04 14:20 GMT+08:00 Baptiste Daroussin :
> >
> > > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> > > > Hi,
> > &
On Mon, Jul 04, 2016 at 02:36:11PM +0800, Huang Wen Hui wrote:
> 2016-07-04 14:20 GMT+08:00 Baptiste Daroussin :
>
> > On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> > > Hi,
> > > On very recent CURRENT, ls can eat high CPU time when LANG=zh
2016-07-04 14:20 GMT+08:00 Baptiste Daroussin :
> On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> > Hi,
> > On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8
> and
> > LC_ALL=zh_CN.UTF-8:
> >
> > % uname -a
> > Fr
On Mon, Jul 04, 2016 at 11:56:36AM +0800, Huang Wen Hui wrote:
> Hi,
> On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8 and
> LC_ALL=zh_CN.UTF-8:
>
> % uname -a
> FreeBSD mbp.gddsn.org.cn 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #121 r302331M: Mon
> Jul 4 10:47
Hi,
On very recent CURRENT, ls can eat high CPU time when LANG=zh_CN.UTF-8 and
LC_ALL=zh_CN.UTF-8:
% uname -a
FreeBSD mbp.gddsn.org.cn 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #121 r302331M: Mon
Jul 4 10:47:27 CST 2016 r...@mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK
amd64
top show:
4457 hwh
On Wed, Nov 25, 2015 at 06:31:16PM +0300, Andrey Chernov wrote:
> On 25.11.2015 18:12, Andrey Chernov wrote:
> > On 25.11.2015 17:35, Baptiste Daroussin wrote:
> >>> BTW, array size looks suspicious:
> >>> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX];
> >>> what MB_LEN_MAX doing
On 25.11.2015 18:12, Andrey Chernov wrote:
> On 25.11.2015 17:35, Baptiste Daroussin wrote:
>>> BTW, array size looks suspicious:
>>> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX];
>>> what MB_LEN_MAX doing here? This constant is for multiple-bytes encoded,
>>> not for wide chars.
On 25.11.2015 17:35, Baptiste Daroussin wrote:
>> BTW, array size looks suspicious:
>> static wchar_t wab_months[12][MAX_ABMON_WIDTH * 2 * MB_LEN_MAX];
>> what MB_LEN_MAX doing here? This constant is for multiple-bytes encoded,
>> not for wide chars.
> Bad copy/paste sorry it should be "MAX_ABMON_W
On Wed, Nov 25, 2015 at 05:06:17PM +0300, Andrey Chernov wrote:
> On 25.11.2015 16:51, Baptiste Daroussin wrote:
> > wcslcat works like strlcat:
> > to quote the manpage:
> > "It will append at most dstsize - strlen(dst) - 1 characters."
> > So here with your version it will be n - wcslen(wab_month
On 25.11.2015 16:51, Baptiste Daroussin wrote:
> wcslcat works like strlcat:
> to quote the manpage:
> "It will append at most dstsize - strlen(dst) - 1 characters."
> So here with your version it will be n - wcslen(wab_months[i]) -1
> which won't fit what we want to do.
>
> btw that makes me figu
On 25.11.2015 15:53, Baptiste Daroussin wrote:
> What I did for now is set max_month_width to -1 and in ls_strftime I fallback
> on
> the plain strftime meaning you keep localized information but the alignement
> is
> broken as of now.
It will be enough.
>> 3) wcwidth/wcswidth may return -1 too
On Wed, Nov 25, 2015 at 04:34:17PM +0300, Andrey Chernov wrote:
> On 25.11.2015 15:53, Baptiste Daroussin wrote:
> > What I did for now is set max_month_width to -1 and in ls_strftime I
> > fallback on
> > the plain strftime meaning you keep localized information but the
> > alignement is
> > bro
s
> >
> > Also added the error checking for the return of wide chars functions. For
> > now I
> > haven't added fallback, suggestions welcome if needed.
>
> 1) For just 1 char in wcswidth(&wab_months[i][j], 1); it is better to
> use another function wcwidth(
On 25.11.2015 4:31, Andrey Chernov wrote:
> 4) The whole processing looks overcomplicated and not effective. What
> about this instead?
> for (i = 0; i < 12; i++) {
> count wcswidth() of each month and store it in wab_months_width[].
> count max_width_month.
> }
> for (i = 0; i < 12; i++) {
1) For just 1 char in wcswidth(&wab_months[i][j], 1); it is better to
use another function wcwidth(wab_months[i][j]);
2) By fallback I mean something which not stops ls working with
incorrect for some reason locale, like setting max_width_month to
MAX_ABMON_WIDTH on error return (from
mbsto
On Wed, Nov 25, 2015 at 01:15:13AM +0100, Baptiste Daroussin wrote:
> On Sat, Nov 21, 2015 at 11:57:46PM +0300, Andrey Chernov wrote:
> > On 21.11.2015 15:18, Ed Schouten wrote:
> > > Hi Baptiste,
> > >
> > > I suppose you should use the wcswidth() function somewhere to compute
> > > the visible w
On Sat, Nov 21, 2015 at 11:57:46PM +0300, Andrey Chernov wrote:
> On 21.11.2015 15:18, Ed Schouten wrote:
> > Hi Baptiste,
> >
> > I suppose you should use the wcswidth() function somewhere to compute
> > the visible width of the month name. Some characters may be
> > double-width, others may have
On 21.11.2015 15:18, Ed Schouten wrote:
> Hi Baptiste,
>
> I suppose you should use the wcswidth() function somewhere to compute
> the visible width of the month name. Some characters may be
> double-width, others may have no effective width at all.
>
I agree. Checking error return of wide chars
Hi Baptiste,
I suppose you should use the wcswidth() function somewhere to compute
the visible width of the month name. Some characters may be
double-width, others may have no effective width at all.
--
Ed Schouten
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
__
org/D4239
>
> The whole function is ugly, not only its name. Please no hardcoded
> constants assuming some internal encoding knowledge, they are wrong for
> non-UTF-8 encodings in any case, use wide chars instead.
>
> BTW, the same 3 chars restriction is in tar, cpio, pax, lots of
g some internal encoding knowledge, they are wrong for
non-UTF-8 encodings in any case, use wide chars instead.
BTW, the same 3 chars restriction is in tar, cpio, pax, lots of ftp
clients, i.e. where 'ls' emulated.
--
http://ache.vniz.net/
signature.asc
Description: OpenPGP digital signature
> > > > subj. http://i.imgur.com/F9QO29l.png
> > > > it is on head@r290573:
> > > > WTR:
> > > > env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env
> > > > LC_ALL=ru_RU.UTF-8
> > > > ls -la /usr/ports/databases/
>
on head@r290573:
> > > WTR:
> > > env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env
> > > LC_ALL=ru_RU.UTF-8
> > > ls -la /usr/ports/databases/
> > > env LC_ALL=C ls -la /usr/ports/databases/ works fine
> > > also on old stable/10 (r286868)
On Fri, Nov 20, 2015 at 11:42:53AM +0100, Baptiste Daroussin wrote:
> On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote:
> > Hi,
> >
> > subj. http://i.imgur.com/F9QO29l.png
> > it is on head@r290573:
> > WTR:
> > env LC_ALL=uk_UA.UT
On Fri, Nov 20, 2015 at 11:05:56AM +0300, Sergey V. Dyatko wrote:
> Hi,
>
> subj. http://i.imgur.com/F9QO29l.png
> it is on head@r290573:
> WTR:
> env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=ru_RU.UTF-8
> ls -la /usr/ports/databases/
>
> env
Hi,
subj. http://i.imgur.com/F9QO29l.png
it is on head@r290573:
WTR:
env LC_ALL=uk_UA.UTF-8 ls -la /usr/ports/databases/ or env LC_ALL=ru_RU.UTF-8
ls -la /usr/ports/databases/
env LC_ALL=C ls -la /usr/ports/databases/ works fine
also on old stable/10 (r286868) as I can see 'month' fi
> On Jun 17, 2015, at 9:35 AM, Andrey Chernov wrote:
>
> Signed PGP part
> On 17.06.2015 16:58, Marcel Moolenaar wrote:
> >
> >> On Jun 16, 2015, at 9:53 PM, Andrey Chernov
> >> wrote:
> >
> >> Should be no any %FF, but single cha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17.06.2015 16:58, Marcel Moolenaar wrote:
>
>> On Jun 16, 2015, at 9:53 PM, Andrey Chernov
>> wrote:
>
>> Should be no any %FF, but single char in pre libxo ls or nothing
>> in post libxo one.
>>
>>
> On Jun 16, 2015, at 9:53 PM, Andrey Chernov wrote:
> Should be no any %FF, but single char in pre libxo ls or nothing in post
> libxo one.
>
> Use
> LANG=ru_RU.KOI8-R
> before touch command. It looks like you create file with name "%FF" instead.
No
a
>problem, provide me with a way to reproduce.
>
>
>touch `printf "\377"`
>env LANG=ru_RU.KOI8-R ls -l | od -bc | grep 377
>
>
>fbsdvm64% touch `printf "\377”`
>fbsdvm64% ls -l | head -2
>total 96
>-rw-r--r-- 1 marcel staff 0 Jun 16 21:25 %FF
>
&
blem, provide me with a way to reproduce.
>
> touch `printf "\377"`
> env LANG=ru_RU.KOI8-R ls -l | od -bc | grep 377
fbsdvm64% touch `printf "\377”`
fbsdvm64% ls -l | head -2
total 96
-rw-r--r-- 1 marcel staff 0 Jun 16 21:25 %FF
fbsdvm64% env LANG=ru_RU.KOI8-R ls -l |
uot;\377"`
env LANG=ru_RU.KOI8-R ls -l | od -bc | grep 377
- --
http://ache.vniz.net/
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJVgO2wAAoJEKUckv0MjfbKm94H/ic8hVCgYX1hFA6YAT8hksHF
+RMrrus4iElF0Dz7sxx4q0CPBhIP2NPVXnNQZUeZwFHe4x/oFC7KYfZH6s74xoU3
AU1orszVWm2OhZ0RiB2CXnbxMhHyDm1gIRLm6sFtvE95S
On 2015-06-16 23:23, Marcel Moolenaar wrote:
>
>> On Jun 16, 2015, at 7:42 PM, Andrey Chernov wrote:
>>
>> On 17.06.2015 5:18, Andrey Chernov wrote:
>>> Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column,
>>> just ls eats whole filen
> On Jun 16, 2015, at 7:42 PM, Andrey Chernov wrote:
>
> On 17.06.2015 5:18, Andrey Chernov wrote:
>> Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column,
>> just ls eats whole filenames with printable national characters inside. Long
>> live l
On 17.06.2015 5:18, Andrey Chernov wrote:
> Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just
> ls eats whole filenames with printable national characters inside. Long live
> libxo.
>
I mean ls -l. To be precise, for 8bit non-C locales at least:
ls -l
On Wed, 17 Jun 2015 05:18:35 +0300
Andrey Chernov wrote:
> Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date
> column, just ls eats whole filenames with printable national
> characters inside. Long live libxo.
> ___
>
Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just
ls eats whole filenames with printable national characters inside. Long live
libxo.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
call to vn_io_fault_iomove in
> ncl_bioread(). So what I do:
>
> 1. reboot
> 2. login
> 3. ls
> -> I see that it is moving 4 blocks 4k each to the user and they look
> fine
> 4. wait half an hour
> 5. ls
> -> now there is only one block, which contains zeros starting
he data just before the call to vn_io_fault_iomove in
> ncl_bioread(). So what I do:
>
> 1. reboot
> 2. login
> 3. ls
>-> I see that it is moving 4 blocks 4k each to the user and they look
> fine
> 4. wait half an hour
> 5. ls
>-> now there is onl
and copying the data out of them.
RM>One thing you might check via printf()s is whether the buffer cache
RM>has the zero'd data in it before it copies it to userland.
I now dump the data just before the call to vn_io_fault_iomove in
ncl_bioread(). So what I do:
1. reboot
2. login
3. ls
l I can think to do is scan the commits that seem to somehow relate
to the buffer cache or copying to userland or ???)
rick
> harti
>
> -Original Message-
> From: Rick Macklem [mailto:rmack...@uoguelph.ca]
> Sent: Tuesday, May 14, 2013 2:50 PM
> To: Brandt, Hartmut
> Cc: cu
Now I've also changed NFS_DIRBLKSIZ to 4k - no change.
harti
-Original Message-
From: Rick Macklem [mailto:rmack...@uoguelph.ca]
Sent: Tuesday, May 14, 2013 2:50 PM
To: Brandt, Hartmut
Cc: curr...@freebsd.org
Subject: Re: files disappearing from ls on NFS
Hartmut Brandt wrote:
>
printfs() here and there to figure out...
harti
-Original Message-
From: Rick Macklem [mailto:rmack...@uoguelph.ca]
Sent: Tuesday, May 14, 2013 2:50 PM
To: Brandt, Hartmut
Cc: curr...@freebsd.org
Subject: Re: files disappearing from ls on NFS
Hartmut Brandt wrote:
> On Mon, 13 May
; RM>> I've updated one of my -current machines this week (previous
> RM>> update
> RM>> RM>> was in
> RM>> RM>> february). Now I see a strange effect (it seems only on NFS
> RM>> mounts):
> RM>> RM>> ls or
> RM>> RM
k (previous
RM>> update
RM>> RM>> was in
RM>> RM>> february). Now I see a strange effect (it seems only on NFS
RM>> mounts):
RM>> RM>> ls or
RM>> RM>> even echo * will list only some files (strange enough the first
RM>> files
RM>&
Hartmut Brandt wrote:
> On Sun, 12 May 2013, Rick Macklem wrote:
>
> RM>Hartmut Brandt wrote:
> RM>> Hi,
> RM>>
> RM>> I've updated one of my -current machines this week (previous
> update
> RM>> was in
> RM>> february). Now I s
On Sun, 12 May 2013, Rick Macklem wrote:
RM>Hartmut Brandt wrote:
RM>> Hi,
RM>>
RM>> I've updated one of my -current machines this week (previous update
RM>> was in
RM>> february). Now I see a strange effect (it seems only on NFS mounts):
RM>> ls o
Hartmut Brandt wrote:
> Hi,
>
> I've updated one of my -current machines this week (previous update
> was in
> february). Now I see a strange effect (it seems only on NFS mounts):
> ls or
> even echo * will list only some files (strange enough the first files
> from
klem [mailto:rmack...@uoguelph.ca]
RM>> Sent: Saturday, May 04, 2013 11:33 PM
RM>> To: Brandt, Hartmut
RM>> Cc: curr...@freebsd.org; Andrzej Tobola
RM>> Subject: Re: files disappearing from ls on NFS
RM>>
RM>> Hartmut Brandt wrote:
RM>> > On Fri, 3 May 2013,
m: Rick Macklem [mailto:rmack...@uoguelph.ca]
> Sent: Saturday, May 04, 2013 11:33 PM
> To: Brandt, Hartmut
> Cc: curr...@freebsd.org; Andrzej Tobola
> Subject: Re: files disappearing from ls on NFS
>
> Hartmut Brandt wrote:
> > On Fri, 3 May 2013, Rick Macklem wrote:
> >
&
d.org; Andrzej Tobola
Subject: Re: files disappearing from ls on NFS
Hartmut Brandt wrote:
> On Fri, 3 May 2013, Rick Macklem wrote:
>
> RM>Ok, if you succeed in isolating the commit, that would be great.
>
> Hmm. I'm somewhat stuck. clang from yesterday can't compile clang
t: Re: files disappearing from ls on NFS
Hartmut Brandt wrote:
> On Fri, 3 May 2013, Rick Macklem wrote:
>
> RM>Ok, if you succeed in isolating the commit, that would be great.
>
> Hmm. I'm somewhat stuck. clang from yesterday can't compile clang from
> a
> mon
RM>> RM>> Hi,
> RM>> RM>>
> RM>> RM>> I've updated one of my -current machines this week (previous
> RM>> update
> RM>> RM>> was in
> RM>> RM>> february). Now I see a strange effect (it seems only on NFS
> RM>
You could try this patch (which is the one to fix readdir for
union mounts), since I can see that VOP_VPTOCNP() will also be broken
without it. (I can't see how that would break "ls", but it breaks __getcwd()
and friends, so maybe it can affect "ls" somehow?)
It's
2013, Rick Macklem wrote:
RM>>
RM>> RM>Hartmut Brandt wrote:
RM>> RM>> Hi,
RM>> RM>>
RM>> RM>> I've updated one of my -current machines this week (previous
RM>> update
RM>> RM>> was in
RM>> RM>> february).
> Hartmut Brandt wrote:
> > On Fri, 3 May 2013, Daniel Braniss wrote:
> >
> > DB>I don't know about current, but on 9.1-stable, the nfsstat -m only
> > works
> > DB>for root! nfsstat can be run by anybody.
> >
> > Same for current. It silently prints nothing. Took me some time
> > to figure out I
Hartmut Brandt wrote:
> Hi,
>
> I've updated one of my -current machines this week (previous update
> was in
> february). Now I see a strange effect (it seems only on NFS mounts):
> ls or
> even echo * will list only some files (strange enough the first files
> from
gt;
> RM>Hartmut Brandt wrote:
> RM>> Hi,
> RM>>
> RM>> I've updated one of my -current machines this week (previous
> update
> RM>> was in
> RM>> february). Now I see a strange effect (it seems only on NFS
> mounts):
> RM>&
Hartmut Brandt wrote:
> On Fri, 3 May 2013, Daniel Braniss wrote:
>
> DB>I don't know about current, but on 9.1-stable, the nfsstat -m only
> works
> DB>for root! nfsstat can be run by anybody.
>
> Same for current. It silently prints nothing. Took me some time
> to figure out I should try as roo
Daniel Braniss wrote:
> > Hartmut Brandt wrote:
> > > Hi,
> > >
> > > I've updated one of my -current machines this week (previous
> > > update
> > > was in
> > > february). Now I see a strange effect (it seems only on NFS
>
> Hartmut Brandt wrote:
> > Hi,
> >
> > I've updated one of my -current machines this week (previous update
> > was in
> > february). Now I see a strange effect (it seems only on NFS mounts):
> > ls or
> > even echo * will list only some file
On Fri, 3 May 2013, Daniel Braniss wrote:
DB>I don't know about current, but on 9.1-stable, the nfsstat -m only works
DB>for root! nfsstat can be run by anybody.
Same for current. It silently prints nothing. Took me some time
to figure out I should try as root...
harti
__
mut Brandt wrote:
RM>> Hi,
RM>>
RM>> I've updated one of my -current machines this week (previous update
RM>> was in
RM>> february). Now I see a strange effect (it seems only on NFS mounts):
RM>> ls or
RM>> even echo * will list only some files (strang
Hartmut Brandt wrote:
> Hi,
>
> I've updated one of my -current machines this week (previous update
> was in
> february). Now I see a strange effect (it seems only on NFS mounts):
> ls or
> even echo * will list only some files (strange enough the first files
> from
week (previous
FC> update was in february). Now I see a strange effect (it seems
FC> only on NFS mounts): ls or even echo * will list only some files
FC> (strange enough the first files from the normal, alphabetically
FC> ordered list). If I change something in the dire
> I've updated one of my -current machines this week (previous update was in
> february). Now I see a strange effect (it seems only on NFS mounts): ls or
> even echo * will list only some files (strange enough the first files from
> the normal, alphabetically ordered list). If I
Hi,
I've updated one of my -current machines this week (previous update was in
february). Now I see a strange effect (it seems only on NFS mounts): ls or
even echo * will list only some files (strange enough the first files from
the normal, alphabetically ordered list). If I change some
t; On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht
>> >> wrote:
>> >>>
>> >>> Thanks. Can you also please remind
>> >>> how to reinstall just /bin/ls,
>> >>> without the "make buildworld"?
>> >>>
>> >
>>>
> >>> Thanks. Can you also please remind
> >>> how to reinstall just /bin/ls,
> >>> without the "make buildworld"?
> >>>
> >>
> >> cp /rescue/ls /bin/ls
> >
> > oh.. of course. I've forgotten
"Daniel O'Connor" writes:
> This is the crunched binary and is pretty big (unlikely to be an issue
> on a modern system though).
>
> You can do..
> cd /usr/src/bin/ls
> make all install
I think you missed the point. Reinstalling ls from broken sources
wasn'
On 20/10/2011, at 22:21, Anton Shterenlikht wrote:
> On Thu, Oct 20, 2011 at 11:58:41AM +0100, Tom Evans wrote:
>> On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht
>> wrote:
>>>
>>> Thanks. Can you also please remind
>>> how to reinstall just
On Thu, Oct 20, 2011 at 11:58:41AM +0100, Tom Evans wrote:
> On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht
> wrote:
> >
> > Thanks. Can you also please remind
> > how to reinstall just /bin/ls,
> > without the "make buildworld"?
> >
&g
On Wed, Oct 19, 2011 at 7:47 PM, Anton Shterenlikht wrote:
>
> Thanks. Can you also please remind
> how to reinstall just /bin/ls,
> without the "make buildworld"?
>
cp /rescue/ls /bin/ls
Cheers
Tom
___
freebsd-current@free
1 - 100 of 204 matches
Mail list logo
