Re: Atomic install(1) by default (was: Re: groff breaks "make -j N buildworld")
On Fri, Apr 20, 2001 at 06:39:30AM +1000, Bruce Evans wrote:
> On Thu, 19 Apr 2001, Ruslan Ermilov wrote:
>
> > On Thu, Apr 19, 2001 at 05:53:53PM +0300, Ruslan Ermilov wrote:
> > > On Thu, Apr 19, 2001 at 11:12:24PM +1000, Bruce Evans wrote:
> > > > atomic installation. Atomic installation (but not -C) should be the
> > > > default.
> > > >
> > > This one seems like an easy task, and this is suspicious... How about
> > > the attached patch? I have tested it lightly, and haven't found any
> > > problems. Will the `make -j32 installworld' of -CURRENT be enough
> > > test to commit this and remove -B from Makefile.inc1?
> > >
> > Damn, forgot to attach the patch. Here it goes...
>
> This seems to be simple enough. A bit too simple :-). The old
> behaviour of deleting the target first is still needed at least
> optionally to handle cases where there is no space for a copy.
>
But then all atomicy goes awry. Should I introduce -r instead (borrowed
from NetBSD)?
: -r Install to a temporary file and then rename the file to its final
: destination name. This can be used for precious files, to avoid
: truncation of the original when error conditions (filesystem full
: etc.) occur.
> Cleaning up the temporary files after a signal is more necessary if -C
> is the default.
>
I didn't mean to volunteer to fix all of the BUGS section :-)
> Index: xinstall.c
> ===
> RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 xinstall.c
> --- xinstall.c2000/10/08 09:17:56 1.40
> +++ xinstall.c2001/04/19 14:38:41
> @@ -53,11 +53,6 @@ static const char rcsid[] =
> * attribute changes and don't clear the dump flag. (I think inode
> * ctimes are not updated for null attribute changes, but this is a
> * bug.)
> - * o independent of -C, if a copy must be made, then copy to a tmpfile,
> - * set all attributes except the immutable flags, then rename, then
> - * set the immutable flags. It's annoying that the immutable flags
> - * defeat the atomicicity of rename - it seems that there must be
> - * a window where the target is not immutable.
> */
>
> The comment still applies to the -C case. We now always make a copy, but
> for -C this is just a waste of time if the comparison succeeds.
>
I fail to understand how this still applies. Could you please exaplain
it in a bit more details?
Also, for -C case, copy is not exactly the waste of time, and this is you
who added the comment below in revision 1.4:
/*
* Unfortunately, because we strip the installed file and not the
* original one, it is impossible to do the comparison without
* first laboriously copying things over and then comparing.
* It may be possible to better optimize the !dostrip case, however.
* For further study.
*/
OTOH, I agree that it is probably makes sense to disable -C and -s
combo:
/*-
* Todo:
* o for -C, compare original files except in -s case.
And have always compare with original files. What do you think?
> ...
> @@ -409,7 +404,7 @@ install(from_name, to_name, fset, flags)
>* It may be possible to better optimize the !dostrip case, however.
>* For further study.
>*/
> - if (docompare) {
> + if (docopy) {
> struct stat old_sb, new_sb, timestamp_sb;
> int old_fd;
> struct utimbuf utb;
> @@ -423,7 +418,7 @@ install(from_name, to_name, fset, flags)
> if (old_sb.st_flags & NOCHANGEBITS)
> (void)fchflags(old_fd, old_sb.st_flags & ~NOCHANGEBITS);
> fstat(to_fd, &new_sb);
> - if (compare(old_fd, old_to_name, to_fd, to_name, &old_sb,
> + if (!docompare || compare(old_fd, old_to_name, to_fd, to_name, &old_sb,
> &new_sb)) {
>
> Line too long.
>
Argh, I recently added allscreens_flags="VGA_90x25" to /etc/rc.conf :-)
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
If you just want an xargs that supports --replstr/-i simply install: ftp://ftp.gnu.org/gnu/findutils or even more easily: /usr/ports/misc/findutils two comments: I don't want to enter a protracted discussion over the benefits/drawbacks of the current xargs vs an updated xargs, nor try to do a write-from-scratch. The cp -d option has runtime execution of O(1). Xargs addes O(n) due to it's manipulation of the arguement vector in -i mode. The process I'm dealing with already takes many hours to run. I want to reduce time, not increase it. Comments welcome. -john - Garance A Drosihn's Original Message - > At 10:08 PM -0700 4/19/01, Dima Dorfman wrote: > >Garance A Drosihn <[EMAIL PROTECTED]> writes: > > > Or maybe something to indicate where the list of arguments > >> should go in a command. Hrm. Let's say '-Y replstr' or > >> '-y[replstr]' (no blank after -y). If no [replstr] is > >> given on -y, it defaults to the two characters '[]'. > >> Then one might do: > >> cat big_file_list | xargs -y cp [] target_directory > > > >This is a great idea! I'm willing to implement it if nobody > >else wants to. > > Woo-hoo! Someone to do the work! Yes! > > > > you're trying to address. On the other hand, the man page > >> for 'xargs' on FreeBSD says: > >> > >>The xargs utility is expected to be IEEE Std 1003.2 > >>(``POSIX.2'') compliant. > >> > >> so I don't know how we go about adding options to it. On > >> the other hand, that same issue is faced by adding options > >> to 'cp', as there is a similar claim made in cp's man page. > > > >I don't think it's a problem. We're adding new options here, not > >changing--sometimes known as breaking--what already exists. I'm > >pretty sure that the standards don't say anything to the effect of, > >"You must support this and nothing else." That'd be rather silly. > > Actually, it's not as silly as it sounds. If you're writing > scripts, and you use those extra parameters, then you'll get > into trouble when running the script on some other POSIX-based > OS which does not have these new options. > > I really do like the idea of both the -I/-i options from solaris, > and the -Y/-y options that I just dreamed up, but I'm not sure > what the right procedure is to introduce them (and eventually > have them standard everywhere... :-). Maybe we could initially > have a 'yargs' command, which is just like 'xargs' except that > it adds those four options. Maybe I'm just overly pedantic. > > Hmm. Checking my copy of "Single Unix Specification, v2", the > -I/-i parameters are defined in THAT standard, but it doesn't > have anything matching my -Y/-y suggestion. Hmm, I wonder if > I should be copying this "meta-question" to the mailing list > for standardizing things... > > -- > Garance Alistair Drosehn= [EMAIL PROTECTED] > Senior Systems Programmer or [EMAIL PROTECTED] > Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
> Garance A Drosihn <[EMAIL PROTECTED]> writes:
> > Or maybe something to indicate where the list of arguments
> > should go in a command. Hrm. Let's say '-Y replstr' or
> > '-y[replstr]' (no blank after -y). If no [replstr] is
> > given on -y, it defaults to the two characters '[]'.
> > Then one might do:
> >cat big_file_list | xargs -y cp [] target_directory
>
> This is a great idea! I'm willing to implement it if nobody else
> wants to.
If you add this (which I think is a good idea), please make it option
free with {} as the default arglist and -i to override that string in
line with sysv's xargs:
find something | xargs cp {} target_directory
or
find something | xargs -i '[]' cp '[]' target_directory
Although it's possible to break something that uses a literal {} as
an argument, I think this is better than introducing semantics
that'll confuse people.
> Dima Dorfman
> [EMAIL PROTECTED]
Cheers.
--
Brian <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Dima Dorfman wrote: > Garance A Drosihn <[EMAIL PROTECTED]> writes: > > Or maybe something to indicate where the list of arguments > > should go in a command. Hrm. Let's say '-Y replstr' or > > '-y[replstr]' (no blank after -y). If no [replstr] is > > given on -y, it defaults to the two characters '[]'. > > Then one might do: > >cat big_file_list | xargs -y cp [] target_directory > > This is a great idea! I'm willing to implement it if nobody else > wants to. > > > you're trying to address. On the other hand, the man page > > for 'xargs' on FreeBSD says: > > > > The xargs utility is expected to be IEEE Std 1003.2 > > (``POSIX.2'') compliant. > > > > so I don't know how we go about adding options to it. On > > the other hand, that same issue is faced by adding options > > to 'cp', as there is a similar claim made in cp's man page. > > I don't think it's a problem. We're adding new options here, not > changing--sometimes known as breaking--what already exists. I'm > pretty sure that the standards don't say anything to the effect of, > "You must support this and nothing else." That'd be rather silly. I don't think that introducing a new option in the tool that expected to be compatible among several systems is a good thing. Once new option is introduced and documented, people would start using it, in many cases even without a notion that this option is FreeBSD specific, which will obviously lead to users' confusion and scripts incompatabilities. The right way to go, IMO, is to introduce a simple wrapper for xargs (say yargs), that it will be clearly documented as a FreeBSD scecific thing. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world (still) having trouble (after gdb.291/gdb/defs.h)
In message <[EMAIL PROTECTED]> David Wolfskill writes: : That said, while I was trying to figure out what had gone wrong, I ended : up chasing something that was "merely" a warning, but loks to me as if : it has some unpleasant potential: the dual (conflicting) definitions of : MDF_ACTIVE, thus: : : sys/pccard/cardinfo.h:81:#define MDF_ACTIVE 0x40/* Context active :(read-only) */ : : and : : sys/sys/memrange.h:18:#define MDF_ACTIVE (1<<27) /* currently active */ : : : The notion of the same program (kdump, in this case) actually using both : include files would seem to be a cause for some concern. Don't worry about it. The person who imported the memcontrol stuff didn't check the system closely enough for conflicts. The pccard define has been around since 1996 while the memcontrol one was added in 1999 and still hasn't been fixed :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic install(1) by default (was: Re: groff breaks "make -j N buildworld")
Hello Bruce! Forget all of this. I started incorporating OpenBSD fixes to install(1). They seem to cover all the cases you have mentioned. I will send a CFR when I finish. They used your revision 1.4 as the base, and implemented all of the todos, and even more. Thanks, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
restore doesn't restore ownership of symbolic link
Hello all,
I will report to all that restore command doesn't restore the
property of symbolic link at all, that is owner, group,
permissions and utime.
Yamazaki-san first reported this issue on USENET at
fj.os.bsd.freebsd. So I'm Cc'ing he and thread participater.
I will propose below quick patch. How do you feel ?
My environment is FreeBSD 4.3RC (today). Sorry I don't have
current environment.
Thanks !
before dump:
mistral# ls -l /mnt4
total 1
-rw-r--r-- 1 root wheel 5 1/ 3 17:33 foo
lrwxr-xr-x 1 yohta wheel 3 3/19 13:17 foos -> foo
restore with 4.3-RC restore:
mistral# dump 0f - /mnt4 | ( cd /tmp/tmp ; restore rf - )
...
mistral# ls -l /tmp/tmp
total 53
-rw-r--r-- 1 root wheel 5 1/ 3 17:33 foo
lrwx-- 1 root wheel 3 4/20 23:17 foos -> foo
-rw--- 1 root wheel 52580 4/20 23:17 restoresymtable
restore with patch'ed restore:
mistral# dump 0f - /mnt4 | ( cd /tmp/tmp ; /home/yohta/restore/restore rf - )
...
mistral# ls -l
total 53
-rw-r--r-- 1 root wheel 5 1/ 3 17:33 foo
lrwxr-xr-x 1 yohta wheel 3 3/19 13:17 foos -> foo
-rw--- 1 root wheel 52580 4/20 23:18 restoresymtable
Here is sample patch:
--- tape.c.orig Fri Apr 20 22:25:10 2001
+++ tape.c Fri Apr 20 23:12:07 2001
@@ -559,6 +559,14 @@
return (genliteraldir(name, curfile.ino));
case IFLNK:
+ {
+ uid_t uid;
+ gid_t gid;
+ int ret;
+
+ uid = curfile.dip->di_uid;
+ gid = curfile.dip->di_gid;
+
lnkbuf[0] = '\0';
pathlen = 0;
getfile(xtrlnkfile, xtrlnkskip);
@@ -567,7 +575,13 @@
"%s: zero length symbolic link (ignored)\n", name);
return (GOOD);
}
- return (linkit(lnkbuf, name, SYMLINK));
+ ret = linkit(lnkbuf, name, SYMLINK);
+ (void) lchown(name, uid, gid);
+ (void) lchmod(name, mode);
+ lutimes(name, timep);
+ /* symbolic link doesn't have any flags */
+ return (ret);
+ }
case IFIFO:
vprintf(stdout, "extract fifo %s\n", name);
--
Yoshihiko SARUMARU
mail: [EMAIL PROTECTED] web: http://www.imasy.or.jp/~mistral/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: core(5) implementation using perl(1)
On Thu, Apr 19, 2001 at 07:00:21PM +0300, Maxim Sobolev wrote: > Attached script forces perl(1) to dump core, which isn't a good > behaviour IMO (tested on 5-CURRENT and 4.3-RC). Why it is definitely not a good behavior for perl(1), the script is not correct anyway. You need to change " to ' to achieve the result you want. I'll try to make a shorter testcase and submit it to perl developers. Cheers, +Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: core(5) implementation using perl(1)
On Fri, Apr 20, 2001 at 04:33:48PM +0200, Anton Berezin wrote:
> On Thu, Apr 19, 2001 at 07:00:21PM +0300, Maxim Sobolev wrote:
>
> > Attached script forces perl(1) to dump core, which isn't a good
> > behaviour IMO (tested on 5-CURRENT and 4.3-RC).
>
> Why it is definitely not a good behavior for perl(1), the script is
> not correct anyway. You need to change " to ' to achieve the result
> you want.
>
> I'll try to make a shorter testcase and submit it to perl developers.
FYI.
Here's the minimal coredump case:
$ perl -n -e 's||${}|g; s|||'
Have not tried with 5.6.1 yet.
Cheers,
=Anton.
--
May the tuna salad be with you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Ogolnopolski Wortal Turystyczny
OGÓLNOPOLSKI WORTAL KRAJOZNAWCZY HTTP://POZNAJKRAJ.PL TWÓJ PRZEWODNIK PO POLSCE Poznajkraj.pl najdynamiczniej rozwijający się w Polsce profesjonalny wortal, prezentujący kompleksową bazę informacji o wypoczynku, rozrywce i kulturze w naszym kraju. Poznajkraj.pl ułatwi Państwu planowanie podróży po Polsce, przedstawiając szeroką gamę informacji o regionach, w które chcieliby się Państwo wybrać. Poznajkraj.pl pomoże Państwu w wyborze, gdzie znaleźć odpowiednią kwaterę, gdzie najlepiej zjeść, gdzie najprzyjemniej spędzić wolny czas. Poznajkraj.pl - piszą dla nas najznakomitsi autorzy przewodników. Poznajkraj.pl - już ponad 400 artykułów z zakresu geografii, historii, etnografii, architektury, przyrodoznawstwa i wielu innych dziedzin; tworzą one swoisty multimedialny przewodnik po Polsce, który pozwoli na lepsze poznanie naszego kraju. Poznajkraj.pl - prognoza pogody, również w systemie WAP. Poznajkraj.pl - czat, galeria sztuki, księgarnia Już wkrótce wortal będzie posiadał angielską, niemiecką i rosyjską wersje językową. ZAPRASZAMY! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: core(5) implementation using perl(1)
Anton Berezin wrote: > On Thu, Apr 19, 2001 at 07:00:21PM +0300, Maxim Sobolev wrote: > > > Attached script forces perl(1) to dump core, which isn't a good > > behaviour IMO (tested on 5-CURRENT and 4.3-RC). > > Why it is definitely not a good behavior for perl(1), the script is > not correct anyway. You need to change " to ' to achieve the result > you want. I know that there is an error. But coredumping is not a best error handling out there ;). > I'll try to make a shorter testcase and submit it to perl developers. Ok, thank you! -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
< said: > '-y[replstr]' (no blank after -y). Prohibited by POSIX. The `xargs' utility ``shall'' follow the Utility Syntax Guidelines. > so I don't know how we go about adding options to it. POSIX is clear on this issue: the implementation may add any options it wishes, provided that those options are documented. Of course, if a POSIX working group happens to choose ``your'' option letter next time they add an option to that utility, you lose. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: restore doesn't restore ownership of symbolic link
It seems good, but shouldn't it be:
ret = linkit(lnkbuf, name, SYMLINK);
if (ret == 0) {
if (lchown(name, uid, gid))
perror(name);
if (lchmod(name, mode))
perror(name);
lutimes(name, timep);
}
/* symbolic link doesn't have any flags */
return (ret);
On Fri, 20 Apr 2001, Yoshihiko SARUMARU wrote:
> Hello all,
>
> I will report to all that restore command doesn't restore the
> property of symbolic link at all, that is owner, group,
> permissions and utime.
>
> Yamazaki-san first reported this issue on USENET at
> fj.os.bsd.freebsd. So I'm Cc'ing he and thread participater.
>
> I will propose below quick patch. How do you feel ?
>
> My environment is FreeBSD 4.3RC (today). Sorry I don't have
> current environment.
>
> Thanks !
>
>
> before dump:
> mistral# ls -l /mnt4
> total 1
> -rw-r--r-- 1 root wheel 5 1/ 3 17:33 foo
> lrwxr-xr-x 1 yohta wheel 3 3/19 13:17 foos -> foo
>
> restore with 4.3-RC restore:
> mistral# dump 0f - /mnt4 | ( cd /tmp/tmp ; restore rf - )
> ...
> mistral# ls -l /tmp/tmp
> total 53
> -rw-r--r-- 1 root wheel 5 1/ 3 17:33 foo
> lrwx-- 1 root wheel 3 4/20 23:17 foos -> foo
> -rw--- 1 root wheel 52580 4/20 23:17 restoresymtable
>
> restore with patch'ed restore:
> mistral# dump 0f - /mnt4 | ( cd /tmp/tmp ; /home/yohta/restore/restore rf - )
> ...
> mistral# ls -l
> total 53
> -rw-r--r-- 1 root wheel 5 1/ 3 17:33 foo
> lrwxr-xr-x 1 yohta wheel 3 3/19 13:17 foos -> foo
> -rw--- 1 root wheel 52580 4/20 23:18 restoresymtable
>
>
> Here is sample patch:
> --- tape.c.orig Fri Apr 20 22:25:10 2001
> +++ tape.cFri Apr 20 23:12:07 2001
> @@ -559,6 +559,14 @@
> return (genliteraldir(name, curfile.ino));
>
> case IFLNK:
> + {
> + uid_t uid;
> + gid_t gid;
> + int ret;
> +
> + uid = curfile.dip->di_uid;
> + gid = curfile.dip->di_gid;
> +
> lnkbuf[0] = '\0';
> pathlen = 0;
> getfile(xtrlnkfile, xtrlnkskip);
> @@ -567,7 +575,13 @@
> "%s: zero length symbolic link (ignored)\n", name);
> return (GOOD);
> }
> - return (linkit(lnkbuf, name, SYMLINK));
> + ret = linkit(lnkbuf, name, SYMLINK);
> + (void) lchown(name, uid, gid);
> + (void) lchmod(name, mode);
> + lutimes(name, timep);
> + /* symbolic link doesn't have any flags */
> + return (ret);
> + }
>
> case IFIFO:
> vprintf(stdout, "extract fifo %s\n", name);
>
> --
> Yoshihiko SARUMARU
> mail: [EMAIL PROTECTED] web: http://www.imasy.or.jp/~mistral/
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
> Apr 19 15:09:31 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, channel dead > Apr 19 15:19:00 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, channel dead can anyone suffering from this problem confirm that the hardware is generating interrupts? use 'systat -vm 1' to watch while you try to play sound. -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[CFR] OpenBSD install(1) fixes: atomic install, etc.
Hi!
The attached patch incorporates most of OpenBSD fixes to install(1).
It does not include manpage update. Most significant changes are:
o All TODOs are acted upon.
o New flags: -b and -B
: -bBackup any existing files before overwriting them by
: renaming them to file.old. See -B for specifying a
: different backup suffix.
:
: -B suffix
: Use suffix as the backup suffix if -b is given.
o New flag: -S (atomic install)
: -SSafe copy. Normally, install unlinks an existing target before
: installing the new file. With the -S flag a temporary file is
: used and then renamed to be the target. The reason this is safer
: is that if the copy or rename fails, the existing target is left
: untouched.
o The -c flag is now the default, and only provided for backwards
compatibility. We now never remove the original file.
o Flags -v and -D were withdrawn.
o strip(1) failure is not considered fatal.
Please review.
Thanks,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: xinstall.c
===
RCS file: /home/ncvs/src/usr.bin/xinstall/xinstall.c,v
retrieving revision 1.40
diff -u -p -r1.40 xinstall.c
--- xinstall.c 2000/10/08 09:17:56 1.40
+++ xinstall.c 2001/04/20 15:42:20
@@ -45,21 +45,6 @@ static const char rcsid[] =
"$FreeBSD: src/usr.bin/xinstall/xinstall.c,v 1.40 2000/10/08 09:17:56 bde Exp $";
#endif /* not lint */
-/*-
- * Todo:
- * o for -C, compare original files except in -s case.
- * o for -C, don't change anything if nothing needs be changed. In
- * particular, don't toggle the immutable flags just to allow null
- * attribute changes and don't clear the dump flag. (I think inode
- * ctimes are not updated for null attribute changes, but this is a
- * bug.)
- * o independent of -C, if a copy must be made, then copy to a tmpfile,
- * set all attributes except the immutable flags, then rename, then
- * set the immutable flags. It's annoying that the immutable flags
- * defeat the atomicicity of rename - it seems that there must be
- * a window where the target is not immutable.
- */
-
#include
#include
#include
@@ -82,45 +67,29 @@ static const char rcsid[] =
#include "pathnames.h"
-/* Bootstrap aid - this doesn't exist in most older releases */
-#ifndef MAP_FAILED
-#define MAP_FAILED ((void *)-1)/* from */
-#endif
-
-int debug, docompare, docopy, dodir, dopreserve, dostrip, nommap, verbose;
-int mode = S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH;
-char *group, *owner, pathbuf[MAXPATHLEN];
-char pathbuf2[MAXPATHLEN];
-
#defineDIRECTORY 0x01/* Tell install it's a directory. */
#defineSETFLAGS0x02/* Tell install to set flags. */
#defineNOCHANGEBITS(UF_IMMUTABLE | UF_APPEND | SF_IMMUTABLE | SF_APPEND)
+#defineBACKUP_SUFFIX ".old"
+struct passwd *pp;
+struct group *gp;
+int dobackup, docompare, dodir, dopreserve, dostrip, nommap, safecopy;
+int mode = S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH;
+char pathbuf[MAXPATHLEN], tempfile[MAXPATHLEN];
+char *suffix = BACKUP_SUFFIX;
+uid_t uid;
+gid_t gid;
+
void copy __P((int, char *, int, char *, off_t));
-intcompare __P((int, const char *, int, const char *,
-const struct stat *, const struct stat *));
+intcompare __P((int, const char *, size_t, int, const char *, size_t));
+intcreate_newfile __P((char *, struct stat *));
+intcreate_tempfile __P((char *, char *, size_t));
void install __P((char *, char *, u_long, u_int));
void install_dir __P((char *));
void strip __P((char *));
-void usage __P((void));
inttrymmap __P((int));
-
-#define ALLOW_NUMERIC_IDS 1
-#ifdef ALLOW_NUMERIC_IDS
-
-uid_t uid = -1;
-gid_t gid = -1;
-
-uid_t resolve_uid __P((char *));
-gid_t resolve_gid __P((char *));
-u_long numeric_id __P((char *, char *));
-
-#else
-
-struct passwd *pp;
-struct group *gp;
-
-#endif /* ALLOW_NUMERIC_IDS */
+void usage __P((void));
int
main(argc, argv)
@@ -132,20 +101,23 @@ main(argc, argv)
u_long fset;
u_int iflags;
int ch, no_target;
- char *flags, *to_name;
+ char *flags, *to_name, *group = NULL, *owner = NULL;
iflags = 0;
- while ((ch = getopt(argc, argv, "CcdDf:g:m:Mo:psv")) != -1)
+ while ((ch = getopt(argc, argv, "BbCcdf:g:Mm:o:pSs")) != -1)
switch((char)ch) {
+ case 'B':
+ suffix = optarg;
+ /* FALLTHROUGH */
+ case 'b':
+ dobackup = 1;
+ break;
case 'C':
- docompare = docopy = 1;
+
Re: sound driver breakage/megapatch
Hello, When was this megapatch? I have a kernel & world from evening of 18th CEST, and my SB 64 AWE rocks as usual. I even figured out, how to play Shoutcast streams with mpg123 which enabled me to listen to my favourite radio on the console:-) Doing it right now:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] OpenBSD install(1) fixes: atomic install, etc.
Hi, Ruslan Ermilov wrote: > The attached patch incorporates most of OpenBSD fixes to install(1). > It does not include manpage update. Most significant changes are: > > o New flag: -S (atomic install) > > : -SSafe copy. Normally, install unlinks an existing target before > : installing the new file. With the -S flag a temporary file is > : used and then renamed to be the target. The reason this is safer > : is that if the copy or rename fails, the existing target is left > : untouched. > Just curious: why not make this way of doing install default (i.e. always use it)? Regards, Konstantin. -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] OpenBSD install(1) fixes: atomic install, etc.
Konstantin Chuguev wrote: > Hi, > > Ruslan Ermilov wrote: > > > The attached patch incorporates most of OpenBSD fixes to install(1). > > It does not include manpage update. Most significant changes are: > > > > o New flag: -S (atomic install) > > > > : -SSafe copy. Normally, install unlinks an existing target before > > : installing the new file. With the -S flag a temporary file is > > : used and then renamed to be the target. The reason this is safer > > : is that if the copy or rename fails, the existing target is left > > : untouched. > > > > Just curious: why not make this way of doing install default (i.e. always use > it)? It may effectively doubles disk space requirements during copy (when destination file is not on a sofdep-enabled partition and is not open at the moment when install(8) unlinks it). For small files it doesn't matter, but for a big ones it could lead to a problem. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] OpenBSD install(1) fixes: atomic install, etc.
On Fri, Apr 20, 2001 at 07:41:36PM +0300, Maxim Sobolev wrote: > Konstantin Chuguev wrote: > > > Hi, > > > > Ruslan Ermilov wrote: > > > > > The attached patch incorporates most of OpenBSD fixes to install(1). > > > It does not include manpage update. Most significant changes are: > > > > > > o New flag: -S (atomic install) > > > > > > : -SSafe copy. Normally, install unlinks an existing target before > > > : installing the new file. With the -S flag a temporary file is > > > : used and then renamed to be the target. The reason this is safer > > > : is that if the copy or rename fails, the existing target is left > > > : untouched. > > > > > > > Just curious: why not make this way of doing install default (i.e. always use > > it)? > > It may effectively doubles disk space requirements during copy (when destination > file is not on a sofdep-enabled partition and is not open at the moment when > install(8) unlinks it). For small files it doesn't matter, but for a big ones it > could lead to a problem. > I think -S should be made the default for `installworld' (this was the main reason that triggered this work). But I don't think this should be turned `on' by default in install(1). BTW, this binary just completed the `installworld' test on -STABLE. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
No, it's not generating interrupts. On Fri, 20 Apr 2001, Cameron Grant wrote: > Date: Fri, 20 Apr 2001 17:06:58 +0100 > From: Cameron Grant <[EMAIL PROTECTED]> > To: Scott Hazen Mueller <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: sound driver breakage/megapatch > > > Apr 19 15:09:31 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, > channel dead > > Apr 19 15:19:00 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, > channel dead > > can anyone suffering from this problem confirm that the hardware is > generating interrupts? > > use 'systat -vm 1' to watch while you try to play sound. > > -cg > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] OpenBSD install(1) fixes: atomic install, etc.
On Fri, Apr 20, 2001 at 08:03:20PM +0300, Ruslan Ermilov wrote: > On Fri, Apr 20, 2001 at 07:41:36PM +0300, Maxim Sobolev wrote: > > Konstantin Chuguev wrote: > > > > > Hi, > > > > > > Ruslan Ermilov wrote: > > > > > > > The attached patch incorporates most of OpenBSD fixes to install(1). > > > > It does not include manpage update. Most significant changes are: > > > > > > > > o New flag: -S (atomic install) > > > > > > > > : -SSafe copy. Normally, install unlinks an existing target before > > > > : installing the new file. With the -S flag a temporary file is > > > > : used and then renamed to be the target. The reason this is safer > > > > : is that if the copy or rename fails, the existing target is left > > > > : untouched. > > > > > > > > > > Just curious: why not make this way of doing install default (i.e. always use > > > it)? > > > > It may effectively doubles disk space requirements during copy (when destination > > file is not on a sofdep-enabled partition and is not open at the moment when > > install(8) unlinks it). For small files it doesn't matter, but for a big ones it > > could lead to a problem. > > > I think -S should be made the default for `installworld' (this was the main > reason that triggered this work). But I don't think this should be turned > `on' by default in install(1). > > BTW, this binary just completed the `installworld' test on -STABLE. > Just tried -j32 installworld with modified install(1) binary for which -S is the default, and it still choked on lib/libncurses. The problem is in bsd.man.mk: we should separate installing of manpages and their MLINKS, otherwise links could be attempted before their originals are installed. Continuing with -DNOMAN now... Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
>> Apr 19 15:09:31 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, >channel dead >> Apr 19 15:19:00 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, >channel dead >can anyone suffering from this problem confirm that the hardware is >generating interrupts? >use 'systat -vm 1' to watch while you try to play sound. Oh, sorry - yes, I can... I watched the pcm interrupt (irq 9 on my box) increment using vmstat -i. I had seen something in the archives about that not happening. \scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
> Oh, sorry - yes, I can... I watched the pcm interrupt (irq 9 on my box) > increment using vmstat -i. I had seen something in the archives about that > not happening. is there any other device using irq 9? -cg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
>> Oh, sorry - yes, I can... I watched the pcm interrupt (irq 9 on my box) >> increment using vmstat -i. I had seen something in the archives about >that >> not happening. >is there any other device using irq 9? vmstat -i interrupt total rate stray irq0 10 stray irq6 10 stray irq7 10 stray irq15 10 ata0 irq14 212797 ata1 irq15 40 atkbd0 irq1 75692 psm0 irq12 27669 10 fdc0 irq6 10 clk irq0 272328 100 ep0 irq5 122422 44 Total 451276 165 [Sound driver is currently not loaded. Putting the .ko files into loader.conf.local hangs the system during boot? Dunno if this is a clue or no.] grep "irq.*9" /var/log/messages Apr 16 09:46:07 zorba /boot/kernel/kernel: pci0: at 8.0 irq 9 Apr 16 09:46:07 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 Apr 17 10:01:53 zorba /boot/kernel/kernel: pci0: at 8.0 irq 9 Apr 17 10:01:53 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 Apr 18 10:10:45 zorba /boot/kernel/kernel: pci0: at 8.0 irq 9 Apr 18 10:10:45 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 Apr 19 14:44:30 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 Apr 19 15:31:00 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 Apr 19 15:53:00 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 Apr 19 18:47:21 zorba /boot/kernel/kernel: pcm0: mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 I'm pretty sure not. \scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound driver breakage/megapatch
I'm sorry, I was wrong, I have the same problem that Scott: # vmstat -i interrupt total rate stray irq0 10 stray irq6 10 stray irq7 10 ata0 irq14 337983 15 ata1 irq15 200 fdc0 irq6 10 atkbd0 irq1 462472 psm0 irq12 229981 clk irq0 2185682 99 rtc irq8 2797782 128 sio1 irq3 251802 11 ed1 irq11 317241 Total 5674242 259 # dmesg |grep "irq 9" pcm0: mem 0xfedf-0xfedf7fff irq 9 at device 9.0 on pci0 daniel.- On Fri, 20 Apr 2001, Daniel wrote: > Date: Fri, 20 Apr 2001 17:40:45 -0300 (ART) > From: Daniel <[EMAIL PROTECTED]> > To: Cameron Grant <[EMAIL PROTECTED]> > Cc: Scott Hazen Mueller <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: sound driver breakage/megapatch > > No, it's not generating interrupts. > > On Fri, 20 Apr 2001, Cameron Grant wrote: > > > Date: Fri, 20 Apr 2001 17:06:58 +0100 > > From: Cameron Grant <[EMAIL PROTECTED]> > > To: Scott Hazen Mueller <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > Subject: Re: sound driver breakage/megapatch > > > > > Apr 19 15:09:31 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, > > channel dead > > > Apr 19 15:19:00 zorba /boot/kernel/kernel: pcm0: play interrupt timeout, > > channel dead > > > > can anyone suffering from this problem confirm that the hardware is > > generating interrupts? > > > > use 'systat -vm 1' to watch while you try to play sound. > > > > -cg > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
missing man's files
FreeBSD ariel.phys.wesleyan.edu 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri Apr 20 11:39:31 EDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARIEL i386 after last build many man's files are missing, they're there but empty. Was it just my badluck ? -Vlad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing man's files
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [010420 12:08] wrote: > FreeBSD ariel.phys.wesleyan.edu 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Fri Apr 20 > 11:39:31 EDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARIEL > i386 > after last build many man's files are missing, they're there but empty. > Was it just my badluck ? I think there was groff breakage. > -Vlad > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- -Alfred Perlstein - [[EMAIL PROTECTED]] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FirewireDirect Gets A New Spark
FirewireDirect is happy to announce the debut and immediate availability of the newest in our series of FireWire storage solutions, the 2.5" Spark II FireWire & USB Portable Hard Drive. The new design means we've retired the number of the original Spark, the popular mobile hard drive that launched our line of FireWire solutions. We've replaced it with an even smaller chassis, and added USB for extra flexability. Come by our web site to see the new package, and order this weekend to receive FREE SHIPPING. Spark II 10GB HDD - $259 Spark II 20GB HDD - $329 Spark II Firewire Enclosure Kit - $119 This offer ends Tuesday, April 24, 200. This is a special offer to subscribers to this list. Please see our web site for info about these offers. --- You are currently subscribed to fwd-newswire as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit our subscription page at http://firewiredirect.com/company/newswire/subscribe.shtml
Re: cp -d dir patch for review (or 'xargs'?)
Folks, although there was much rejoicing, I think there's no need for a new option to cp. Just use the toolbox, it's not too hard: (cat bigfilelist; echo destdir) | xargs cp Or even echo destdir >>bigfilelist xargs cp < bigfilelist should do the trick. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jens Schweikhardt wrote: > although there was much rejoicing, I think there's no need for a > new option to cp. Just use the toolbox, it's not too hard: > > (cat bigfilelist; echo destdir) | xargs cp > > Or even > > echo destdir >>bigfilelist > xargs cp < bigfilelist > > should do the trick. Err, neither of those will work if there are too many filenames for a single invokation of "cp" since none but the last will get the "destdir" argument. -- Ben Smithurst / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
> > Folks, > > although there was much rejoicing, I think there's no need for a > new option to cp. Just use the toolbox, it's not too hard: > > (cat bigfilelist; echo destdir) | xargs cp > > Or even > > echo destdir >>bigfilelist > xargs cp < bigfilelist > > should do the trick. No, it won't. Consider a list of files a, b, c, d. You create input to xargs 'a b c d destdir', which it then splits into 'a b c' and 'd destdir'. The first time cp is run, it will probably fail; the second time only 'd' ends up where you expect it. The best solution to this is actually to fix xargs to accept a "command format string", eg. echo list | xargs "cp %s destdir" Probably a better way to do it would be to have the insertion marker an option to xargs: echo list | xargs -s LIST_HERE cp LIST_HERE destdir -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
[ attempting to consolidate two identical threads into one ]
Brian Somers <[EMAIL PROTECTED]> writes:
> I agree - the script idea doesn't seem right.
>
> If {} isn't allowed to implicitly mean ``all the arguments that'll
> fit'', then I'd vote for using -i (a version that does full grouping)
> although I would not vote for the semantics whereby -i must either be
> followed directly with the replacement string (with no intervening
> spaces) or else have an implicit {} replacement string, ie we should
> have these meaning the same thing:
>
> xargs -i '<<<>>>' command blah '<<<>>>' blah
> xargs -i'<<<>>>' command blah '<<<>>>' blah
I honestly don't understand the differnece between this and the -y
option gad described. Nevertheless, it seems that pretty much
everyone agrees that something like this is a good idea.
Attached is a patch that adds a -Y option to xargs which does, well,
pretty much what I imagine the above would do. Here are a couple of
examples:
dima@spike% cat test# test input
this is just
a test; it has
no real purpose
in life
dima@spike% ./xargs -Y {} echo CMD LINE ARGS < test
CMD LINE ARGS this is just a test; it has no real purpose in life
dima@spike% ./xargs -Y {} echo {} CMD LINE ARGS < test
this is just a test; it has no real purpose in life CMD LINE ARGS
dima@spike% ./xargs -Y {} echo CMD {} LINE ARGS < test
CMD this is just a test; it has no real purpose in life LINE ARGS
dima@spike% ./xargs -Y {} echo CMD LINE {} ARGS < test
CMD LINE this is just a test; it has no real purpose in life ARGS
dima@spike% ./xargs -Y {} echo CMD LINE ARGS {} < test
CMD LINE ARGS this is just a test; it has no real purpose in life
dima@spike% ./xargs -n 2 -Y {} echo CMD LINE {} ARGS < test
CMD LINE this is ARGS
CMD LINE just a ARGS
CMD LINE test; it ARGS
CMD LINE has no ARGS
CMD LINE real purpose ARGS
CMD LINE in life ARGS
I'm not sure the patch is entirely correct. xargs seems to be overly
complicated in the way it does some of its processing, but it works
and I believe I managed to maintain most of the assumptions it makes.
Comments? Suggestions?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: xargs.c
===
RCS file: /st/src/FreeBSD/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.9
diff -u -r1.9 xargs.c
--- xargs.c 1999/08/28 01:07:50 1.9
+++ xargs.c 2001/04/20 22:37:15
@@ -73,6 +73,8 @@
int cnt, indouble, insingle, nargs, nflag, nline, xflag, wasquoted;
char **av, *argp, **ep = env;
long arg_max;
+ int apargs = 0;
+ char **avv, *replstr = NULL;
/*
* POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
@@ -96,7 +98,7 @@
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
nflag = xflag = wasquoted = 0;
- while ((ch = getopt(argc, argv, "0n:s:tx")) != -1)
+ while ((ch = getopt(argc, argv, "0n:s:txY:")) != -1)
switch(ch) {
case 'n':
nflag = 1;
@@ -115,6 +117,9 @@
case '0':
zflag = 1;
break;
+ case 'Y':
+ replstr = optarg;
+ break;
case '?':
default:
usage();
@@ -144,6 +149,13 @@
else {
cnt = 0;
do {
+ if (replstr && strcmp(*argv, replstr) == 0) {
+ apargs = 1;
+ *argv++;
+ for (avv = argv; *avv; *avv++)
+ cnt += strlen(*avv) + 1;
+ break;
+ }
cnt += strlen(*bxp++ = *argv) + 1;
} while (*++argv);
}
@@ -211,6 +223,8 @@
if (xp == exp || p > ebp || ch == EOF) {
if (xflag && xp != exp && p > ebp)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs && *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
if (ch == EOF)
@@ -253,6 +267,8 @@
if (xflag)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs && *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
Re: your unsubscribe request
As you requested, you have been unsubscribed from 'fwd-newswire'. --- Return-Path: <[EMAIL PROTECTED]> Received: from mailhost.sparknet.net ([207.67.22.123]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Fri, 20 Apr 2001 18:04:41 -0500 Received: from don-oakes.sparklist.com (dhcp-client-26.sparklist.com [207.250.191.151]) by mailhost.sparknet.net (8.10.1/8.10.1) with ESMTP id f3KN6oI12670 for <[EMAIL PROTECTED]>; Fri, 20 Apr 2001 18:06:50 -0500 Message-Id: <[EMAIL PROTECTED]> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 20 Apr 2001 17:59:06 -0500 To: fwd-newswire-request From: "SparkLIST.com Abuse" <[EMAIL PROTECTED]> Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed # Mail sent to leave-fwd-newswire-2059525t was converted to these commands: unsubscribe fwd-newswire [EMAIL PROTECTED] confirm end # This is the text of the message that triggered the action: Return-Path: <[EMAIL PROTECTED]> Received: from mailhost.sparknet.net ([207.67.22.123]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Fri, 20 Apr 2001 18:04:41 -0500 Received: from don-oakes.sparklist.com (dhcp-client-26.sparklist.com [207.250.191.151]) by mailhost.sparknet.net (8.10.1/8.10.1) with ESMTP id f3KN6oI12670 for <[EMAIL PROTECTED]>; Fri, 20 Apr 2001 18:06:50 -0500 Message-Id: <[EMAIL PROTECTED]> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 20 Apr 2001 17:59:06 -0500 To: [EMAIL PROTECTED] From: "SparkLIST.com Abuse" <[EMAIL PROTECTED]> Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Atomic install(1) by default (was: Re: groff breaks "make -j Nbuildworld")
> Forget all of this. I started incorporating OpenBSD fixes to install(1). > They seem to cover all the cases you have mentioned. I will send a CFR > when I finish. They used your revision 1.4 as the base, and implemented > all of the todos, and even more. Ah, good. Rev.1.4 sure was a long time ago. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel core
I'm gettind kernel core dumps in the weirdest places with a -current from early today. One place it coredumps is when I run "chsh", another is during a certain part of make install on XFree86-4, the same place every time. I can get some more details if this is an unknown bug. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: kernel core
On 21-Apr-01 David W. Chapman Jr. wrote: > I'm gettind kernel core dumps in the weirdest places with a -current from > early today. One place it coredumps is when I run "chsh", another is during > a certain part of make install on XFree86-4, the same place every time. I > can get some more details if this is an unknown bug. Is it always a sig 11? Can you cvsup or cvs update to specific dates to track down which commit started causing these as well? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
> > Folks, > > although there was much rejoicing, I think there's no need for a > new option to cp. Just use the toolbox, it's not too hard: > > (cat bigfilelist; echo destdir) | xargs cp I like this version of the patch!! It's much much cleaner than hacking up cp or xargs, it even follows the unix principle of using simple tools and glueing them togeather to do bigger jobs, is unix implementation independent, and is very clear in what it does. [You even taugh this old dog a new trick he totally blanked out on!!] > > Or even > > echo destdir >>bigfilelist > xargs cp < bigfilelist > > should do the trick. I don't like this one, bigfilelist gets modified and may need to be used again for something else. Please don't commit this version of the patch :-) > Regards, > > Jens > -- > Jens Schweikhardt http://www.schweikhardt.net/ > SIGSIG -- signature too long (core dumped) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world (still) having trouble (after gdb.291/gdb/defs.h)
On Fri, 20 Apr 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> David Wolfskill writes: > : The notion of the same program (kdump, in this case) actually using both > : include files would seem to be a cause for some concern. > > Don't worry about it. The person who imported the memcontrol stuff > didn't check the system closely enough for conflicts. The pccard > define has been around since 1996 while the memcontrol one was added > in 1999 and still hasn't been fixed :-) Building with "mkioctls -s" also shows many conflicting numeric ioctl values (probably many more than in 1996). This is mostly another non- problem, since the conflicting values mostly go to different drivers, but it prevents utilities like kdump from interpreting ioctl numbers unambiguously. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote: > > (cat bigfilelist; echo destdir) | xargs cp > > I like this version of the patch!! It's much much cleaner than > hacking up cp or xargs, it even follows the unix principle of > using simple tools and glueing them togeather to do bigger > jobs, is unix implementation independent, and is very clear > in what it does. It's clean, simple, and unfortunately, totally bogus. Try: echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo Now consider what would happen with the above suggested construct with a very long file list. I don't see a problem with adding an option to cp to treat the first argument as the target instead of the last argument. It's a simple solution, the code change is simple, and it produces the exact desired result. What's the problem? -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel core
Here's an exact error message because I'm sure I wrongly diagnosed it. Fatal trap 12: pagefault while in kernel mode fault code = supervisor read, page not present kernel: type 12 trap, code = 0 stopped atffs_valloc+0x8eicmpb$0,0(%edi,%eax,1) I can still try to play around with cvs dates if needed, just give me a clue on how far back I should start. Its been over a month since I've cvsuped -current besides this morning. - Original Message - From: "John Baldwin" <[EMAIL PROTECTED]> To: "David W. Chapman Jr." <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, April 20, 2001 9:08 PM Subject: RE: kernel core > > On 21-Apr-01 David W. Chapman Jr. wrote: > > I'm gettind kernel core dumps in the weirdest places with a -current from > > early today. One place it coredumps is when I run "chsh", another is during > > a certain part of make install on XFree86-4, the same place every time. I > > can get some more details if this is an unknown bug. > > Is it always a sig 11? Can you cvsup or cvs update to specific dates to track > down which commit started causing these as well? > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
> Try: > > echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo > > Now consider what would happen with the above suggested construct with > a very long file list. > > I don't see a problem with adding an option to cp to treat the first > argument as the target instead of the last argument. It's a simple > solution, the code change is simple, and it produces the exact desired > result. What's the problem? Unfortunatly, cp is not alone in needing this feature. I think a more sensable approach would be to add an "append args" flag to xargs. For example "--", which could be used like so: xargs cp -- destdir <
Re: cp -d dir patch for review (or 'xargs'?)
> On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote: > > > > (cat bigfilelist; echo destdir) | xargs cp > > > > I like this version of the patch!! It's much much cleaner than > > hacking up cp or xargs, it even follows the unix principle of > > using simple tools and glueing them togeather to do bigger > > jobs, is unix implementation independent, and is very clear > > in what it does. > > It's clean, simple, and unfortunately, totally bogus. > > Try: > > echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo > > Now consider what would happen with the above suggested construct with > a very long file list. bleck... try this for your sample: $ (echo 1 2 3 4 5 6 7 8 9 | xargs -n 4) | while read x; do > echo -n $x; echo " dst" > done 1 2 3 4 dst 5 6 7 8 dst 9 dst $ > > I don't see a problem with adding an option to cp to treat the first > argument as the target instead of the last argument. It's a simple > solution, the code change is simple, and it produces the exact desired > result. What's the problem? It's yet another non-portable option. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel core
I just tried to do an installkernel on a new kernel I built and I got the same error except the last line changed to stopped atffs_dirpref+0x210movzbl0(%ECX,%EAX,1),%EAX Do I have any hope at recovering from this or should I start again with 4 and upgrade to -current. I'm assuming is a problem with the kernel and without being able to update the kernel and install a new one, I don't think I can fix it. - Original Message - From: "David W. Chapman Jr." <[EMAIL PROTECTED]> To: "John Baldwin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, April 20, 2001 9:45 PM Subject: Re: kernel core > Here's an exact error message because I'm sure I wrongly diagnosed it. > > Fatal trap 12: pagefault while in kernel mode > fault code = supervisor read, page not present > kernel: type 12 trap, code = 0 > stopped atffs_valloc+0x8eicmpb$0,0(%edi,%eax,1) > > > I can still try to play around with cvs dates if needed, just give me a clue > on how far back I should start. Its been over a month since I've > cvsuped -current besides this morning. > > - Original Message - > From: "John Baldwin" <[EMAIL PROTECTED]> > To: "David W. Chapman Jr." <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, April 20, 2001 9:08 PM > Subject: RE: kernel core > > > > > > On 21-Apr-01 David W. Chapman Jr. wrote: > > > I'm gettind kernel core dumps in the weirdest places with a -current > from > > > early today. One place it coredumps is when I run "chsh", another is > during > > > a certain part of make install on XFree86-4, the same place every time. > I > > > can get some more details if this is an unknown bug. > > > > Is it always a sig 11? Can you cvsup or cvs update to specific dates to > track > > down which commit started causing these as well? > > > > -- > > > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Boot hang with pcm
Current as of yesterday afternoon hangs trying to boot on my box with an OPTi931 soundcard installed. It prints the probe, and then hangs. With boot -v, the messages are pcm0: at port 0x5 34-0x537,0x380-0x38b,0x220-0x22f,0xe0c-0xe0f irq 5 drq 0,1 on isa0 mss_init: opti_offset=2 Yanking the card, or removing the driver from the kernel config allows the machine to boot fine. Unfortunatly, I just upgraded from a September 2000 vintage -current, so I don't know when this broke. David -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
