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 (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DD11A158094 for ; Fri, 2 Sep 2022 20:29:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A278FE096A; Fri, 2 Sep 2022 20:29:14 +0000 (UTC) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 678F0E090F for ; Fri, 2 Sep 2022 20:29:14 +0000 (UTC) Received: by mail-vs1-xe36.google.com with SMTP id f185so3173158vsc.4 for ; Fri, 02 Sep 2022 13:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=Xm1/QhoC/m8oSEAwCQSotnsxuzgcqhN1AqT25bRYoq4=; b=OY6OmBlN/YHTz0fYDx3zcGGr5OxdudFT6ilGhrK3XSEqnjsKXmwx5aPZyQ9Su0Uehw gbEs2gT0LdcvVAgEJ6lNjfzxO/ujWuIsA2Rlm2OzJ9JxcyE4kB1tf/xHSlZChNChFzuV EycyLm35E533wBsIdfZWozDPpPejXoAMk1QsgeXQ1vZAoAHqUI0WwM8RMfOLSdpa0Cit f52ZWKVn8icM3akGMJa0CPyRimuxQXmBniLNc3bQw5nXhEYOQE8gjAZ6Edk1BBuybLNa Y00HL3BwaWXama5HohMAwR2BSefQed3u5vH0vM0NeViG2xQLtIeWVgz0I+eHlP0lBgTy cYhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=Xm1/QhoC/m8oSEAwCQSotnsxuzgcqhN1AqT25bRYoq4=; b=76YC45Ts6/VNx3X9Lk6PZtCX9At+u4za5Zea+AXwaYW1cyU+DvjuLceAzsL3bjux/+ ExMsrenvfvwsm9uz2wbssaDkfh5Xlr2rwZe6QYYwEieBdG0TV45Jd4nEAHc4N2Y7MypH SRNPpKbMCC00puFF0GLvID3aghOUt4Helw7YMkWwdPaAqjUiNByX3xvrt10Mp1YZt+5X kTrQOkCdLWNf2MI1FZuIajUfwxA70ItqEqPLFpRVDsZQgbdaDEx/JZxyDH0OBLUK4A2v WiWMPCabC+yHy9yEvypwLFRzQfyNUv1sl9XLOpJ6gahREGvzH0RmODM2DFZAbgkKSYzU 2VYw== X-Gm-Message-State: ACgBeo2yodnU+/+u4q38UfjxY4kIZkbTaUG/0UASe0HEvvq4U4O1aYvP JuokZu6+by7TCsA0zmRIobVUnuiSsvY40GSpvXrcx4VE X-Google-Smtp-Source: AA6agR4EnlJA6GA/jeHKyAob02PqYVRORhPYnmBsfgtP4e38EqvSN/H1C8IbNRjdPjeQdEyN+fac6gxVju2+hAPFqEQ= X-Received: by 2002:a05:6102:3353:b0:38c:9170:a96b with SMTP id j19-20020a056102335300b0038c9170a96bmr12419376vse.26.1662150553528; Fri, 02 Sep 2022 13:29:13 -0700 (PDT) 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 References: <98d16301-9555-10de-6828-ceab211f6eed@gmail.com> In-Reply-To: <98d16301-9555-10de-6828-ceab211f6eed@gmail.com> From: "Sebastiaan L. Zoutendijk" Date: Fri, 2 Sep 2022 20:29:01 +0000 Message-ID: Subject: Re: [gentoo-user] rsync not deleting removed directory and drive PW DIS 3.3v question To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 31df446d-52cc-45f3-8f2e-4c8e2c921709 X-Archives-Hash: 0efda7e2a9f0d4025dcf87b89e4cb53f Dear Dale, On Friday 2 September 2022, 3.35am -0500, Dale wrote: > time rsync -auv --progress --delete /home/dale/Desktop/Crypt/Video/* > /mnt/10tb/Video/ What is going on here is due to a subtle interplay of rsync=E2=80=99s synta= x and shell wildcard expansion. You can read about the details of rsync syntax in its man page, but I=E2=80=99ll illustrate here: rsync has two ways to specify a source directory. 1. Without a trailing slash: `rsync path1/source path2/dest`. This syncs path1/source -> path2/dest/source. 2. With a trailing slash: `rsync path1/source/ path2/dest`. This syncs path1/source -> path2/dest. Note that the two ways lead to different target directories getting synced with the source directory. I think the command you are looking for is therefore time rsync -auv --progress --delete /home/dale/Desktop/Crypt/Video /mnt/10t= b or time rsync -auv --progress --delete /home/dale/Desktop/Crypt/Video/ /mnt/10tb/Video NOTE: I have not tested these commands, I would advise you to run them with --dry-run first. Now, why is your original command not deleting the old subdirectory? Let me illustrate this with another example. Suppose we have the same directories as in my first example, path1/source and path2/dest. Now suppose path1/source contains subdirectories foo and bar. These were synced with path2/dest, which therefore also contains foo and bar. Now you rename foo to foo-1 in your source directory. So we have $ ls path1/source foo-1 bar $ ls path2/dest foo bar When you type path1/source/*, it therefore gets expanded to: path1/source/foo-1 path1/source/bar That=E2=80=99s two different source directories, rsync will sync each separately to a subdirectory of the same name (because there is no trailing slash) under path2/dest: path1/source/foo-1 -> path2/dest/foo-1 path1/source/bar -> path2/dest/bar And what about path2/dest/foo? Well, it is not included in these two syncs, so rsync leaves it untouched. The --delete option only affects what is under your sources and targets, here foo-1 and bar, not foo. So, to conclude, what you probably want is to use one of the rsync commands I listed above, which sync the entire source directory with the target, and will clean up anything under the target that is not under the source. Instead, what your old command was doing is to look at every subdirectory and file of the source one by one, which will miss anything in the target that does not have a corresponding item in the source. I hope this helps, Sincerely, Bas -- Sebastiaan L. Zoutendijk =E2=80=A2 slzoutendijk@gmail.com