From nobody Wed Apr 27 09:50:39 2022 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BB8961AADA83 for ; Wed, 27 Apr 2022 09:50:59 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpDXL3znNz3jPS for ; Wed, 27 Apr 2022 09:50:58 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-oi1-x22b.google.com with SMTP id l203so1427725oif.0 for ; Wed, 27 Apr 2022 02:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w9HsnfBmNaUK9PiKRwDvj3IcruQdLQGVwKeMPl9i5b8=; b=jua6lwPmHTTBXkNm6Jk5zDajHgbRFWm6rlUn36EEtQgAUNRbJJpWCWVbN2appndirR E3wWEVggValDk2oAYcxcc9QjqmnCisyrHXRlLEhH4jfPmI/3zY6nozCCFVAwPuBFTB2T UTXSFnu6A3Lm+Dzz8Pf1SVqUeopQewcVPisCbCJCf3CAwB24ELM3ZcspqJW+60xxhzrZ Hw0WbiiCdH/BjZp5WP8OthjnhdWER2S0nPwfUjvWinUqydefgPACR37JZVBhsMKiBBCy T4QVMalP8Soq1H6jqtUrO0UvOxVr8TiANAksFuJBQpz440jiHczkn8YnujzaKJmkyxBH 3GfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w9HsnfBmNaUK9PiKRwDvj3IcruQdLQGVwKeMPl9i5b8=; b=18No35Z+5uiJkOtcga8C+U5ZFwY9aE8fec12Or1WtCT4jhJrFF/zZw+yTq/h0WA9TZ TtLRdoZ8gLvMdX3lhvNPQEdTehbw3FRfkQ+aYKO6Xf3m8Jf8cV2ouS+xnF2nk3M4CfBK PKbmXBDfqhCjoHmX6OWUJxasbvk6GFAk4Vmfc6m8A37ejEMR1yhaa3VHLIrGiYZIOkOb F/AhxZuMsFyil0pYo/unDLLy0xjYa2KDeOuoAgxDPbkjghFsHYsljlwwk7I3fxe5pRfp UEZuIARVbfH3ti2srZJ3v4sKpsDLLzUmU6m1wu19yDCsGxmlPYBpPOr5/8H3ns1papSK +P7g== X-Gm-Message-State: AOAM533Hn84ssrNigv/O61alib34SPQSZJUVevpf99L/mtosDNTwn0Mp sx50g9+fM8QyoXhBxyJobLxSfmDMYrFQfItC X-Google-Smtp-Source: ABdhPJz70dvwJRDuvB0317WWnwq+KBjgvh/jGf2uG0Jsiaea6a//+jjUiUxgcn5OeaqAWIEpbCoGbA== X-Received: by 2002:a54:4791:0:b0:325:715d:db8b with SMTP id o17-20020a544791000000b00325715ddb8bmr1998714oic.74.1651053052458; Wed, 27 Apr 2022 02:50:52 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com. [209.85.167.174]) by smtp.gmail.com with ESMTPSA id v5-20020a0568301bc500b00604fdc97d31sm5821153ota.39.2022.04.27.02.50.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Apr 2022 02:50:52 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id r8so1373512oib.5 for ; Wed, 27 Apr 2022 02:50:51 -0700 (PDT) X-Received: by 2002:a05:6808:1984:b0:322:fe3b:561e with SMTP id bj4-20020a056808198400b00322fe3b561emr15110996oib.175.1651053051659; Wed, 27 Apr 2022 02:50:51 -0700 (PDT) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 References: <40ed09f1-f4b9-d4bf-26fa-9a93e73b09bb@netfence.it> In-Reply-To: <40ed09f1-f4b9-d4bf-26fa-9a93e73b09bb@netfence.it> From: Tomek CEDRO Date: Wed, 27 Apr 2022 11:50:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Fill a disk with more recent files To: Andrea Venturoli Cc: ports Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KpDXL3znNz3jPS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=jua6lwPm; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::22b) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; DMARC_NA(0.00)[cedro.info]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22b:from,209.85.167.174:received]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[ports]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 27, 2022 at 10:09 AM Andrea Venturoli wrote: > On 4/27/22 09:51, Tomek CEDRO wrote: > > On Wed, Apr 27, 2022 at 9:48 AM Andrea Venturoli wrote: > >> Hello. > >> Suppose I have a large storage of files and a smaller disk (backup). > >> I need to copy as much as I can from source to target and I want the > >> most recent files. > >> Before I start scripting and reinvent the wheel, is there some tool already? > > rsync :-) > Thanks for your answer. > Rsync is what I've been using up to now. > However I fail to find an option to tell it to sort the file from most > recent to older. What is it? rsync uses its own order as stated in man page: SORTED TRANSFER ORDER Rsync always sorts the specified filenames into its internal transfer list. This handles the merging together of the contents of identically named directories, makes it easy to remove duplicate filenames, and may confuse someone when the files are transferred in a different order than what was given on the command-line. If you need a particular file to be transferred prior to another, either separate the files into different rsync calls, or consider using --delay-updates (which doesn't affect the sorted transfer order, but does make the final file-updating phase happen much more rapidly). If you want to enforce particular sort order you will have to call rsync from another tool. Probably ls / find, sort, then rsync, maybe a dedicated Python script. That also depends on how do you want to treat existing backup files. Do you want to delete them all completely on backup, or remove oldest files in order to make a room for the new files? Have you considered ZFS (full/incremental) snapshots and partitioning your pool into areas based on backup priority? I use this method. With ZFS you can frequently create incremental snapshots for important locations and stream them into a backup file. Having smaller locations to backup also makes initial full snapshot smaller and that allows full workspace recovery. ZFS also allows quick access to a single files from selected snapshots by entering pool/this/was/my/work/folder/top/.zfs when its on the pool so you do not have to even copy/extract anything. Sorry I do not know any better out-of-the box solution matching your needs. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info