On Mon, Jan 20, 2025 at 00:08:54 +, David wrote:
> I would have recognised this
> echo a{1..5}b
> as brace expansion, but I hadn't absorbed the extra glorious
> capabilities of its commas.
The commas were the original form. The .. range feature was added in
bash version 3.0.
On Sun, 19 Jan 2025 at 16:24, Greg Wooledge wrote:
> On Sun, Jan 19, 2025 at 12:43:51 -0300, Eduardo M KALINOWSKI wrote:
> > Em 19/01/2025 08:57, David escreveu:
> > > On Sun, 19 Jan 2025 at 02:51, Default User
> > > wrote:
> > > > time sudo rsync -aHSx
On Sun, Jan 19, 2025 at 12:43:51 -0300, Eduardo M KALINOWSKI wrote:
> Em 19/01/2025 08:57, David escreveu:
> > On Sun, 19 Jan 2025 at 02:51, Default User
> > wrote:
> > > time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids --
> > > info=progress2,sta
Em 19/01/2025 08:57, David escreveu:
On Sun, 19 Jan 2025 at 02:51, Default User wrote:
time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids --
info=progress2,stats2,name2 --
exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*&quo
On Sat, 18 Jan 2025 21:01:14 -0700
Charles Curley wrote:
> I suggest that instead of using rsync directly you use rsnapshot. You
> can set it up so that it only copies if DRIVE2 is there. The cron
> entries let it happen automatically.
Another advantage to rsnapshot is that you don&
On Sun, 19 Jan 2025 at 02:51, Default User wrote:
> I may just delete everything on DRIVE2 overnight, and then try rsync
> with:
>
> time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids --
> info=progress2,stats2,name2 --
> exclude={"/dev/*","/proc/*&
On 2025-01-19, e...@gmx.us wrote:
> I've never used LUKS before, so we're even. With a non-encrypted
> filesystem, you would
> unmount the partition
> mkfs -t whatever /dev/whatever
> mount it again
It's the same with luks and the device used is a mapping in /dev/mapper
On Sat, Jan 18, 2025 at 08:27:17PM -0500, Default User wrote:
> Hi!
[...]
> Every night, I have been using rsync to copy from DRIVE1 to DRIVE2,
> doing:
>
> time sudo rsync -avvv --human-readable --delete --numeric-ids
> --info=progress2,stats2,name2 --
> exclude={&qu
On 1/18/25 22:21, Default User wrote:
> Hi, Eben!
>
> I hate to sound stupid, but how would I do that. I have never used mkfs
> before.
I've never used LUKS before, so we're even. With a non-encrypted
filesystem, you would
unmount the partition
mkfs -t whatever /dev/whatever
mount it again
s----- 3.6T 1.2T 2.3T
35% /media/user/DRIVE2
sudo du -sh /media/user/DRIVE2
1.2T/media/user/DRIVE2
Every night, I have been using rsync to copy from DRIVE1 to DRIVE2,
doing:
time sudo rsync -avvv --human-readable --delete --numeric-ids
--info=progress2,st
Hi, Charles!
Thanks for the reply.
I will have to ponder that.
On Sat, 18 Jan 2025 20:36:42 -0500
Default User wrote:
> So, back to the original question: what in the world am I supposed to
> do to have rsync copy so that the size change in the two drives is
> equal, and DRIVE2 has (theoretically) the same data, taking up the
> same space, a
Hi, Eben!
I hate to sound stupid, but how would I do that. I have never used mkfs
before.
On 1/18/25 21:50, Default User wrote:
> Hi Andy!
>
> Thanks for the reply.
>
> I may just delete everything on DRIVE2 overnight,
Might be faster to mkfs than to rm *.
Hi Andy!
Thanks for the reply.
I may just delete everything on DRIVE2 overnight, and then try rsync
with:
time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids --
info=progress2,stats2,name2 --
exclude={"/dev/*","/proc/*","/sys/*","/tmp/*",&q
Hi Default,
On Sat, Jan 18, 2025 at 08:36:42PM -0500, Default User wrote:
> So, back to the original question: what in the world am I supposed to
> do to have rsync copy so that the size change in the two drives is
> equal, and DRIVE2 has (theoretically) the same data, taking up the sam
IVE2
sudo du -sh /media/user/DRIVE2
1.2T/media/user/DRIVE2
Every night, I have been using rsync to copy from DRIVE1 to DRIVE2,
doing:
time sudo rsync -avvv --human-readable --delete --numeric-ids
--info=progress2,stats2,name2 --
exclude={"/dev/*","/proc/*","/sys/*&
IVE2
sudo du -sh /media/user/DRIVE2
1.2T/media/user/DRIVE2
Every night, I have been using rsync to copy from DRIVE1 to DRIVE2,
doing:
time sudo rsync -avvv --human-readable --delete --numeric-ids
--info=progress2,stats2,name2 --
exclude={"/dev/*","/proc/*","/sys/*&
>
> > > > https://security-tracker.debian.org/tracker/source-package/rsync
> > >
> > > https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-rsync-could-allow-for-remote-code-execution_2025-007
> >
> > Okay, I'll try one more time.
>
gt;
> Updated included popt to version 1.19.
>
> Fixed a bug with --sparse --inplace where a trailing gap in the source file
> would not clear out the trailing data in the destination file.
>
> Fixed an buffer overflow in the checksum2 code if SHA1 is being used for th
On Fri, Jan 17, 2025 at 10:57:53PM +0100, poc...@homemail.com wrote:
Has the following been Fixed or back ported to 3.2.7?
Stop trolling. If you want to use arch, go use arch and be happy.
> Sent: Friday, January 17, 2025 at 2:11 PM
> From: "Andy Smith"
> To: debian-user@lists.debian.org
> Subject: Re: A warning about rsync in stable: it became broken 3 days ago, is
> now fixed
>
> Hi,
>
> On Fri, Jan 17, 2025 at 03:42:48AM +0100, poc...@
Hi,
On Fri, Jan 17, 2025 at 03:42:48AM +0100, poc...@homemail.com wrote:
> > From: "Andy Smith"
> > You can verify this at:
> >
> > https://security-tracker.debian.org/tracker/source-package/rsync
>
> https://www.cisecurity.org/advisory/multiple-
17 Jan 2025 14:33:05 Roberto C. Sánchez :
> Others, for various reasons, choose a stable distribution to which
> security patches are backported.
In particular Debian testing shouldn't be recommended to users as it is the
least likely to have security patches!
On Fri, Jan 17, 2025 at 12:55:19PM +0100, poc...@homemail.com wrote:
>
>
> > Sent: Thursday, January 16, 2025 at 10:34 PM
> > From: "Stefan Monnier"
> > To: debian-user@lists.debian.org
> > Subject: Re: A warning about rsync in stable: it bec
> Sent: Thursday, January 16, 2025 at 10:34 PM
> From: "Stefan Monnier"
> To: debian-user@lists.debian.org
> Subject: Re: A warning about rsync in stable: it became broken 3 days ago, is
> now fixed
>
> > Why use 3 year old rsync?
>
> If you can't
> Why use 3 year old rsync?
If you can't answer this question, then you probably will be better
served with Debian testing, Debian unstable, or even some other
distribution than Debian stable.
Stefan
> Sent: Thursday, January 16, 2025 at 9:36 PM
> From: "Andy Smith"
> To: debian-user@lists.debian.org
> Subject: Re: A warning about rsync in stable: it became broken 3 days ago, is
> now fixed
>
> Hi,
>
> On Fri, Jan 17, 2025 at 03:27:26AM +0100, poc...
Hi,
On Fri, Jan 17, 2025 at 03:27:26AM +0100, poc...@homemail.com wrote:
> Actually the last patched debian rsync version is still vulnerable
> https://kb.cert.org/vuls/id/952657
>
> rsync 3.4.1 is the latest version that fixes the issues.
That page was last updated 15 January where
> Sent: Thursday, January 16, 2025 at 6:40 PM
> From: "David"
> To: "debian-user"
> Subject: A warning about rsync in stable: it became broken 3 days ago, is now
> fixed
>
> Hi,
>
> For anyone not subscribed to debian-security-announce mailing l
Hi,
For anyone not subscribed to debian-security-announce mailing list:
1) You should subscribe to it :)
2) rsync received a security update 3 days ago [1] with multiple fixes.
3) But that update also introduced a regression in the rsync -H option
(preserves hard links).
4) That regression
rsync works perfectly well i apologize for whining it was a simple permissions
issue. oh what you have to put up with ...
Yours sincerely
Richardh Bostrom
Sent with [Proton Mail](https://proton.me/) secure email.
On Friday 09 February 2024 04:41:37 pm hw wrote:
> On Fri, 2024-02-09 at 11:34 -0500, Roy J. Tellason, Sr. wrote:
> > On Friday 09 February 2024 06:07:16 am hw wrote:
> > > What other manufacturers could we buy UPSs from?
> >
> > I have a Tripp-Lite sitting next to me here that replaced an APC an
hw wrote:
> On Fri, 2024-02-09 at 06:44 -0500, Dan Ritter wrote:
> > hw wrote:
> > > On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote:
> > > > [...]
> > > That sucks. I didn't know that they don't stand behind their
> > > products, and it makes APC not recommendable any longer.
> > >
> > > W
On Fri, 2024-02-09 at 11:34 -0500, Roy J. Tellason, Sr. wrote:
> On Friday 09 February 2024 06:07:16 am hw wrote:
> > What other manufacturers could we buy UPSs from?
>
> I have a Tripp-Lite sitting next to me here that replaced an APC and
> has 2-1/2 times the capabiliity. Been in service sever
On Fri, 2024-02-09 at 06:44 -0500, Dan Ritter wrote:
> hw wrote:
> > On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote:
> > > [...]
> > That sucks. I didn't know that they don't stand behind their
> > products, and it makes APC not recommendable any longer.
> >
> > What other manufacturers cou
>> What other manufacturers could we buy UPSs from?
> I have a Tripp-Lite sitting next to me here that replaced an APC and has
> 2-1/2 times the capabiliity. Been in service several weeks and so far I'm
> pretty happy with it...
Would they accept a warranty claim without having to run some
propri
On Friday 09 February 2024 06:07:16 am hw wrote:
> What other manufacturers could we buy UPSs from?
I have a Tripp-Lite sitting next to me here that replaced an APC and has 2-1/2
times the capabiliity. Been in service several weeks and so far I'm pretty
happy with it...
--
Member of the tou
hw wrote:
> On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote:
> > [...]
> That sucks. I didn't know that they don't stand behind their
> products, and it makes APC not recommendable any longer.
>
> What other manufacturers could we buy UPSs from?
Liebert at the high end, CyberPower at the lo
On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote:
> [...]
> Someone on the apcupsd mailing list thinks I have a faulty UPS or
> battery and should get a replacement.
>
> APC refuses to proceed with a warranty claim because they don't
> support apcupsd or nut, only their own proprietary Powerchu
On 2024-02-08, Charles Curley wrote:
> On Thu, 8 Feb 2024 15:29:21 +
> Andy Smith wrote:
>
>> I do not overly want to buy a Windows licence, run it
>> in a VM and pass USB through to that VM just to try this.
>
> You could try wine. You might need the more recent crossover-office,
> which is
On Thu, 8 Feb 2024 15:29:21 +
Andy Smith wrote:
> I do not overly want to buy a Windows licence, run it
> in a VM and pass USB through to that VM just to try this.
You could try wine. You might need the more recent crossover-office,
which is proprietary (but contributes greatly to wine).
--
Hello,
On Sun, Jan 28, 2024 at 06:55:04PM +, Andy Smith wrote:
> So, I must admit, I am quite tempted by BX1600MI which would cost me
> about £183. The equivalent spec in the Pro range is more than twice
> this price.
[ TL;DR: While free software like apcupsd or nut support all APC
models t
On 1/28/24 13:55, Andy Smith wrote:
Hi,
Thanks, this is very useful.
On Sun, Jan 28, 2024 at 06:58:08PM +0100, hw wrote:
However, stay away from their cheap models as seen on this[1] picture
(Back UPS). They work and you can replace the batteries yourself even
though you're not supposed to.
On Sun, 28 Jan 2024 19:19:55 +0100
hw wrote:
Hello hw,
>How do you know in advance when the battery will have failed?
Even my very basic UPS (APC Backup 1400) has a light on the front
labelled "Replace Battery". That, combined with a very annoying high
pitch scream, are pretty good motivators
Hi,
Thanks, this is very useful.
On Sun, Jan 28, 2024 at 06:58:08PM +0100, hw wrote:
> However, stay away from their cheap models as seen on this[1] picture
> (Back UPS). They work and you can replace the batteries yourself even
> though you're not supposed to. It's a minimum basic device. It
On Fri, 2024-01-26 at 15:56 +, Michael Kjörling wrote:
> On 26 Jan 2024 16:11 +0100, from h...@adminart.net (hw):
> > I rather spend the money on new batteries (EUR 40 last time after 5
> > years) every couple years [...]
To comment myself, I think was 3 years, not 5, sorry.
> > The hardware
On Fri, 2024-01-26 at 15:17 +, Andy Smith wrote:
> Hi,
>
> On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote:
> > I've never had issues with any UPS due to self tests. The batteries
> > need to be replaced when they are worn out. How often that is
> > required depends on the UPS and the con
On Fri, 2024-01-26 at 16:27 +, Michael Kjörling wrote:
> On 26 Jan 2024 16:39 +0100, from h...@adminart.net (hw):
> [...]
> > Having multiple generations of backups already increases the needed
> > storage space by a bit more than half. That makes it already arguable
> > if it's better to make
On Fri, 2024-01-26 at 16:11 +0100, hw wrote:
> I've never had issues with any UPS due to self tests. The batteries
> need to be replaced when they are worn out. How often that is
> required depends on the UPS and the conditions it is working in,
> usually every 3--5 years.
It was with some small
On Fri, 26 Jan 2024, David Wright wrote:
On Fri 26 Jan 2024 at 19:03:33 (+0100), Roger Price wrote:
I currently have two Eaton Ellipse ECO 1600's. ... The four screws are deeply
recessed and difficult to see. They have different heads: some are Torx 10,
others are a star.
20/20 hindsight m
On Fri 26 Jan 2024 at 19:03:33 (+0100), Roger Price wrote:
> I currently have two Eaton Ellipse ECO 1600's. I change the batteries
> every 4-5 years, but this is not as easy as it should be. It is not
> evident that only one of the four back panel screws needs to be
> removed. I took me a while
On Fri, 26 Jan 2024, Andy Smith wrote:
Out of interest what brand of UPS do you recommend for home use that
has easily-replaceable batteries every 3–5 years? For a load of
about 300W.
I currently have two Eaton Ellipse ECO 1600's. I change the batteries every 4-5
years, but this is not as ea
On 26 Jan 2024 16:39 +0100, from h...@adminart.net (hw):
>> RAID is for uptime.
>
> It's also for saving you from the hassle involved with loosing data
> when a disk fails.
Which translates to more quickly fully recovering from the loss of a
storage device.
When used for redundancy and staying w
On 26 Jan 2024 16:11 +0100, from h...@adminart.net (hw):
> I rather spend the money on new batteries (EUR 40 last time after 5
> years) every couple years [...]
>
> The hardware is usually extremely difficult --- and may be impossible
> --- to replace.
And let's not forget that you can _plan_ to
On Thu, 2024-01-18 at 13:09 +, Michael Kjörling wrote:
> On 18 Jan 2024 13:26 +0100, from r...@h5.or.at (Ralph Aichinger):
> > As a home/SOHO user, I'd rather have a working backup every few hours
> > or every day than some RAID10 wonder
>
> Definitely agree that a solid backup regimen (includ
On Fri, 26 Jan 2024, Andy Smith wrote:
> Hi,
>
> On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote:
>> I've never had issues with any UPS due to self tests. The batteries
>> need to be replaced when they are worn out. How often that is
>> required depends on the UPS and the conditions it is wor
Hi,
On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote:
> I've never had issues with any UPS due to self tests. The batteries
> need to be replaced when they are worn out. How often that is
> required depends on the UPS and the conditions it is working in,
> usually every 3--5 years.
Out of int
On Thu, 2024-01-18 at 13:26 +0100, Ralph Aichinger wrote:
> Hello fellow Debian users,
>
> On Thu, 2024-01-18 at 12:18 +0100, hw wrote:
>
> > Always use an UPS.
>
>
> Here I have a somewhat contrarian view, I hope not to offend too much:
It's not offending, you merely have a different opinion.
On 2024-01-18, Andy Smith wrote:
> Could check the man page then like I said.
>
> Some options require rsync to know the full file list, so these
> options disable the incremental recursion mode. These include:
> --delete-before, --delete-after, --prune-empty-dirs, an
On Thu, 2024-01-18 at 21:44 +, Andy Smith wrote:
> Hello,
>
> On Thu, Jan 18, 2024 at 10:01:46PM +0100, Michel Verdier wrote:
> > On 2024-01-18, Andy Smith wrote:
> > > If you use --delete-after (and some other options) then rsync has
> > > to
> > >
Hello,
On Thu, Jan 18, 2024 at 10:01:46PM +0100, Michel Verdier wrote:
> On 2024-01-18, Andy Smith wrote:
> > If you use --delete-after (and some other options) then rsync has to
> > check every file before it can do any work, whereas normally it will
> > find a few files
On 2024-01-18, Andy Smith wrote:
> If you use --delete-after (and some other options) then rsync has to
> check every file before it can do any work, whereas normally it will
> find a few files to work on and start work, meanwhile incrementally
> scanning for more.
Not sure of that.
>> > However, I have read that using rsync --delete instead of rsync --
>> > delete-after is faster and uses less memory, and so is more efficient.
>> I'd be surprised if it makes a significant difference.
> If you use --delete-after (and some other options) then
Hello,
On Wed, Jan 17, 2024 at 11:09:35PM -0500, Stefan Monnier wrote:
> > However, I have read that using rsync --delete instead of rsync --
> > delete-after is faster and uses less memory, and so is more efficient.
>
> I'd be surprised if it makes a significant
On Thu, 2024-01-18 at 13:09 +, Michael Kjörling wrote:
>
> Definitely agree that a solid backup regimen (including regular
> automated backups; at least one off-site copy _at least_ of critical,
> hot data; and planning for the contingency that you need to restore
> that backup onto a brand ne
On 18 Jan 2024 13:26 +0100, from r...@h5.or.at (Ralph Aichinger):
> As a home/SOHO user, I'd rather have a working backup every few hours
> or every day than some RAID10 wonder
Definitely agree that a solid backup regimen (including regular
automated backups; at least one off-site copy _at least_
drive (maybe using an additional
> configuration file)?
You can safely rsync entire rsnapshot backups if you use --hard-links
option to preserve links set by rsnapshot. You have to rsync "entire"
rsnapshot directory else it can't set correct hard links.
Hello fellow Debian users,
On Thu, 2024-01-18 at 12:18 +0100, hw wrote:
> Always use an UPS.
Here I have a somewhat contrarian view, I hope not to offend too much:
For countries with stable electricity supplies (like Austria where I
live) having a small UPS might actually lead to more problems
hat case, a backup with more than one "back"
> version would be more useful (see --link-dest in rsync for that).
>
> It is not against the system running amok and thrashing all attached
> disks (be it by accident -- improbable, or by malice -- more probable.
> cf. c
On Wed, 2024-01-17 at 14:52 -0500, Default User wrote:
> On Wed, 2024-01-17 at 10:29 -0800, Kushal Kumaran wrote:
> > On Wed, Jan 17 2024 at 11:19:39 AM, Default User
> > wrote:
> > > Hello!
> > >
> > > Opinions, please.
> > >
> > >
he situation you fat-finger something and react
before the next backup happens (this is a threat worth being taken
into account). For that case, a backup with more than one "back"
version would be more useful (see --link-dest in rsync for that).
It is not against the system running amok and t
y backup drive might be corrupted or deleted before
> being copied to the secondary backup drive. Then if it is not present
> on the primary backup drive, rsync dutifully deletes it from the
> secondary backup drive. If the file is no longer on the computer's
> internal SSD,
ing of a scenario where a
file on the primary backup drive might be corrupted or deleted before
being copied to the secondary backup drive. Then if it is not present
on the primary backup drive, rsync dutifully deletes it from the
secondary backup drive. If the file is no longer on the computer&
> However, I have read that using rsync --delete instead of rsync --
> delete-after is faster and uses less memory, and so is more efficient.
I'd be surprised if it makes a significant difference.
Stefan
On 2024-01-17, Default User wrote:
> By "glitch", I mean anything that could interfere with the rsync copy
> process. Possible causes:
Whatever the cause you just have to get return code and restart rsync
until it complete succesfully. Then you are sure to have an exact co
On Wed, 2024-01-17 at 09:19 -0800, David Christensen wrote:
> On 1/17/24 08:19, Default User wrote:
> > Hello!
> >
> > Opinions, please.
> >
> > I use rsync to copy my primary backup drive to a secondary backup
> > drive
> > , so that the seco
On 18/1/24 04:19, David Christensen wrote:
> I use rsync to copy my primary backup drive to a secondary backup drive
Good morning
I wonder why both processes don't copy from the original data; so that
you don't copy a potential glitch in the first backup?
on a separate
Hi,
On Wed, Jan 17, 2024 at 02:52:49PM -0500, Default User wrote:
> By "glitch", I mean anything that could interfere with the rsync copy
> process. Possible causes:
> - electrical outages, voltage spikes, voltage drops, "brownouts"
> - mechanical failure
>
ith options to rsync won't offer you that in light of
several of the scenarios you listed, though; not least a lightning
strike. A lightning strike will blow out the drive just as much no
matter what options you're using to invoke rsync.
What you need is really rather multiple copies.
I
On Wed, 2024-01-17 at 10:29 -0800, Kushal Kumaran wrote:
> On Wed, Jan 17 2024 at 11:19:39 AM, Default User
> wrote:
> > Hello!
> >
> > Opinions, please.
> >
> > I use rsync to copy my primary backup drive to a secondary backup
> > drive
> > , so
On Wed, Jan 17 2024 at 11:19:39 AM, Default User
wrote:
> Hello!
>
> Opinions, please.
>
> I use rsync to copy my primary backup drive to a secondary backup drive
> , so that the secondary backup drive is theoretically always an exact
> copy of the primary backup drive.
On 1/17/24 08:19, Default User wrote:
Hello!
Opinions, please.
I use rsync to copy my primary backup drive to a secondary backup drive
, so that the secondary backup drive is theoretically always an exact
copy of the primary backup drive.
Here is the rsync command I use:
time sudo rsync
Hello!
Opinions, please.
I use rsync to copy my primary backup drive to a secondary backup drive
, so that the secondary backup drive is theoretically always an exact
copy of the primary backup drive.
Here is the rsync command I use:
time sudo rsync -aAXHxvv --delete-after --numeric-ids
On Fri, Nov 24, 2023 at 08:13:03AM -0500, Dan Ritter wrote:
> In case people didn't see the announcment:
> --
>
> The worldwide Debian mirrors network has served archive.debian.org via both
> HTTP and rsync. As part of improving the reliability of the service for
> us
In case people didn't see the announcment:
--
The worldwide Debian mirrors network has served archive.debian.org via both
HTTP and rsync. As part of improving the reliability of the service for users,
the Debian mirrors team is separating the access methods to different host
names:
nstallation, very few packages) installed with
> borgbackup and rsync.
>
> I am now very satisfied, much more streamlined than OpenMediaVault.
>
> Am I wrong, are my statements completely off?
>
> Or how does your backup look like?
>
> cheers
> Jason
>
>
Another OM
On 1/9/23 12:44, Jason wrote:
Or how does your backup look like?
I had a QNAP NAS but it became so incredibly slow I replaced it with
Debian using Samba and SSH.
The backups are managed by the clients, but periodically I save part of
the NAS to Amazon S3.
I also have a remote Nextclou
and rsync.
I am now very satisfied, much more streamlined than OpenMediaVault.
Am I wrong, are my statements completely off?
Or how does your backup look like?
cheers
Jason
OpenPGP_0x0D0C34B5DF58FE9D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital
is safer than general purpose synchronizing tools.
A single branch may be pushed to an "upstream" or a "backup" repository
without permanently adding it as a remote by specifying path to that
repository
git push user@host:/path/to/repository.git master
I would limi
On Tue, 22 Aug 2023 19:27:57 +
Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> On 22 Aug 2023 14:33 -0400, from cele...@gmail.com (Celejar):
> >> Git tends to be very rsync-friendly.
> >
> > I do something similar - I use syncthing to automatically keep the
On 22 Aug 2023 14:33 -0400, from cele...@gmail.com (Celejar):
>> Git tends to be very rsync-friendly.
>
> I do something similar - I use syncthing to automatically keep the git
> repositories on two of my machines in sync. rsync may be better, but
> syncthing has more or less w
On 3/11/23, Greg Wooledge wrote:
...
> Hmm, that didn't work either. Now it's time to read the documentation.
> (read, read, read)
> OK, here we go:
>
> unicorn:/tmp/src$ rsync -a --include="*/" --include="*.foo"
> --include="*.bar" --e
OK. Let me just discard every single piece of quoted content from this
thread, because none of it makes ANY sense.
Here is what I see in the Subject: header:
1) Some piece of the verbose output of rsync, for unknown reason.
2) A question about how to do a specific task with rsync.
At some
On 3/11/23, Dan Ritter wrote:
> Albretch Mueller wrote:
>> The one liner reporting that error is:
>>
>> time( sudo rsync --rsync-path="/usr/local/bin/rsync" --debug=ALL
>> --archive --verbose --compress --recursive --checksum --include="*/"
&g
Albretch Mueller wrote:
> The one liner reporting that error is:
>
> time( sudo rsync --rsync-path="/usr/local/bin/rsync" --debug=ALL
> --archive --verbose --compress --recursive --checksum --include="*/"
> --include=".${_X}" --exclude=&qu
The one liner reporting that error is:
time( sudo rsync --rsync-path="/usr/local/bin/rsync" --debug=ALL
--archive --verbose --compress --recursive --checksum --include="*/"
--include=".${_X}" --exclude="*" --prune-empty-dirs "${_SRC
Samuel Wales wrote:
> i seem to get sluggish interactive x pointer etc. on rare occasions
> with rsync. i use nocache nice ionice -c3. i am wondering why chrt
> exists also, and what teh best set of options is for this kind of
> purpose.
Tell us about your hardware and network.
i seem to get sluggish interactive x pointer etc. on rare occasions
with rsync. i use nocache nice ionice -c3. i am wondering why chrt
exists also, and what teh best set of options is for this kind of
purpose.
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy
On 2022-05-08 18:27, AC wrote:
On 2022-05-08 18:03, David wrote:
On Mon, 9 May 2022 at 10:53, AC wrote:
On 2022-05-08 16:45, David wrote:
On Mon, 9 May 2022 at 07:24, AC wrote:
Now here's a new discovery on the machines having problems: as a normal
user I can rsync just fine to a r
1 - 100 of 1191 matches
Mail list logo
