From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A7683158042 for ; Tue, 5 Nov 2024 15:38:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12090E08E2; Tue, 5 Nov 2024 15:38:16 +0000 (UTC) Received: from smarthost01a.sbp.mail.zen.net.uk (smarthost01a.sbp.mail.zen.net.uk [212.23.1.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C1AFEE08CA for ; Tue, 5 Nov 2024 15:38:15 +0000 (UTC) Received: from [82.69.80.10] (helo=cube.localnet) by smarthost01a.sbp.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1t8LdA-00CZBu-U4 for gentoo-user@lists.gentoo.org; Tue, 05 Nov 2024 15:38:14 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Getting tar to keep going Date: Tue, 05 Nov 2024 15:38:13 +0000 Message-ID: <2962590.e9J7NaK4W3@cube> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-Originating-smarthost01a-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 6ea6fb8e-813b-40f7-8bf5-c108c1feff60 X-Archives-Hash: 685b6a8e2d723bbe2f806d1578fb8a8b Greetings. The Network Manager man page says to 'chattr +i /etc/resolv.conf', so I did, and that one move enabled the wireless network to work as it should. Now I find it causes a problem when restoring a backup: tar fails in restoring that file, of course, and reports an error. The number of files restored is less than expected, so I assume that tar stops restoring and just continues to spin through the rest of the tarball without doing anything. Is that right? I've tried setting the options --ignore-command-error and --ignore-failed- read, separately, but with no effect. Is there a way to tell tar to 'keep going', as with portage? If not, I'm going to have to mess about with 'chattr [+/-]i' with all the opportunities that has for error. I don't need any more of those, thank-you-very-much! -- Regards, Peter.