From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (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 lists.proxmox.com (Postfix) with ESMTPS id BAE0EB06E for ; Wed, 6 Apr 2022 12:10:37 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A917F29365 for ; Wed, 6 Apr 2022 12:10:07 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 47BC929347 for ; Wed, 6 Apr 2022 12:10:03 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 1BA734259F for ; Wed, 6 Apr 2022 12:10:03 +0200 (CEST) Message-ID: <9ca6551c-b095-d758-6cd7-7c6169ba94b4@proxmox.com> Date: Wed, 6 Apr 2022 12:09:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Wolfgang Bumiller Cc: Dietmar Maurer , Proxmox Backup Server development discussion References: <1074870458.1383.1649233576312@webmail.proxmox.com> <71ae28f0-e07f-8190-d669-388f5515f99b@proxmox.com> <20220406093053.b62eyoonznsnjm3v@olga.proxmox.com> From: Dylan Whyte In-Reply-To: <20220406093053.b62eyoonznsnjm3v@olga.proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.661 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.631 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [PATCH proxmox-backup] fix #3613: catalog_shell: include matched dir's contents on restore X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2022 10:10:37 -0000 On 4/6/22 11:30, Wolfgang Bumiller wrote: > On Wed, Apr 06, 2022 at 11:15:28AM +0200, Dylan Whyte wrote: >> On 4/6/22 10:26, Dietmar Maurer wrote: >>>> On 04/04/2022 6:19 PM Dylan Whyte wrote: >>>> >>>> Prior to this, during an interactive restore, if a directory was matched >>>> via a pattern match or selection, only the empty directory would be >>>> restored, and not its contents. >>> Why not simply use "**" if you want to restore a whole tree? >> I had originally thought about this, but there are some good reasons for the >> patch: >> >> * I believe there is an expectation when selecting a directory for >> restore, that you would like for the entire directory to be restored >> (unless any sub-directory is explicitly excluded). >> * The 'select' command doesn't do pattern matching, so it wouldn't be >> able to use '**' to restore the directory. This point doesn't apply >> to 'find' and 'restore --pattern'. > Fair points. > I don't have particularly hard feelings about this behavior other than > that it's a change people who're already used to it might not expect. > >> * With the current implementation, '**' won't restore empty >> sub-directories of a matched directory, in spite of the fact that >> they appear in the match list. > That sounds like a bug. Just to clarify, would you like me to fix only this specific bug and otherwise leave the old behavior in place, so that the trailing '/**' is still required to restore a directory's contents? > > Now, with your patch getting rid of the `matches_stack` to keep track > of whether or not we're currently extracting, have you tested nested > alternating include-excludes? > > include a/ > exclude a/b > include a/b/c > > where upon leaving from 'c' to 'b' we need to be back in 'exclude' mode > and when leaving from 'b' to 'a' we need to be back in 'include' mode? Regarding this, the patch currently just skips any excluded items, so an excluded directory is not traversed. I decided that items inside excluded directories probably aren't meant to be matched, but if you'd like it to behave otherwise, I can rethink it :)