Hello,
> [...] I don't know why there is this new problem on my
> machine, but it is not because of the new version of
> rsync. So, I think we can close the report.
Indeed, this doesn't look like a bug in the package itself so marking
this as "Invalid". But that said, from your logs..
> rsync:
* Installation of Ubuntu kubuntu-18.04-desktop-amd64 in VirtualBox
* Creation of user "toto" passwd is "clown". The name of virtual machine is
toto-VirtualBox
* Installation of rsync 3.1.2-2.1ubuntu1.4 and encfs 1.9.2-2build2
* Creation of two directories (by toto) "Backup" and
I let the details of the test in the following message.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1955347
Title:
rsync works bad with encfs now
Status in rsync
Hello,
perdon for the delay, but the Covid is not a sympatical illness. :-(
I have just finished the test of encfs with the older rsync's version
(3.1.2-2.1) on a virtual machine. The problem (IO error encountered -- skipping
file deletion) is still there, so it looks like there is no bug with
Hi Claude,
to reproduce the steps you could do it in a newly installed 20.04 up to
date install.
Once installed you will start fresh with a newly encrypted directory then you
write on your note sheet (text editor for instance):
"Creating directory "MyEncryptedDir" (for instance),
then continue
Hi Utkarsh Gupta,
I understand better what is a step-by-step reproducer :-)
I have tried to downgrade rsync with apt-get install rsync=3.1.3-8 and
there is no change. But the version who seemed to work on my PC was
older rsync_3.1.2-2.1
I've tried to install it but apt-get refused.
Is there a way
Hi Claude,
You could provide step-by-step reproducer by mentioning the exact steps
that one could follow to reproduce the bug in a clean environment.
If you could provide steps/commands that I can copy-paste in a Docker or
an LXD container, then that'd really help us and we can take it from
Hi Bryce and Sergio
I did not downgrade rsync yet, so I will do it using
apt-get install rsync=3.1.3-8
I will do the test with this previous version, but how can I provide a
step-by-step reproducer for this bug ?
With --verbose option or something else ?
Thanks.
Claude
Le lundi 24 janvier 2022
Hello Claude,
It should be straightforward to downgrade the package on Focal, because
the previous version is still in the -release pocket. You can simply:
# apt install rsync=3.1.3-8
and it should do the trick.
While at it, would it be possible for you to provide a step-by-step
reproducer
Hi Claude,
Were you able to downgrade to see if the prior version works properly,
as Lucas suggested? If you haven't yet done so, I'd recommend using apt
rather than co-installation from a tarball in this case both because
it'd be a better apples-to-apples check, and because the behavior will
be
Hi Lucas,
I wanted to do this to make the test, but because of all the
dependencies, I'm scared to make a big mistake if I do it using apt ou
dpkg.
I'd like to install the previous and the actuel versions side by side,
but I have to learn to do it before. Maybe with a tar archive?
Thanks.
Claude
Hi Claude,
Are you able to roll rsycn back to version 3.1.3-8 to see if this gets
fixed? In 2021-11-16, we got an update to fix LP #1896251. FWIW, this is
the upstream patch that was applied:
https://github.com/WayneD/rsync/commit/af6118d98b3482cbcfc223bf2a0777bc19eccb02
--
You received this
Hi Athos,
so you mean that this patch is in focal and the error I'm talking about
is a IOERR_GENERAL error?
I thought no, but I may be mistaken (surely) :-)
today's versions of rsync and encfs are
rsync 3.1.3-8ubuntu0.1
encfs 1.9.5-1build2
and Ubuntu's version was (and is) focal Ubuntu 20.04.3
Hi Micouin,
The bug you linked does include a patch which is available in focal
(20.04). This means that the error you are seing is indeed caused by a
IOERR_GENERAL error. As for
> Why before rsync and encfs worked well together and not now?
would you mind describing which versions of both
No. It's only this changing of behavior who makes me think of a bug.
(of rsync or of encfs?) Why before rsync and encfs worked well together
and not now?
I noticed that encfs is still working correctly when encrypting. I also
noticed that rsync is now refusing the file deletion because of the IO
It seems to be like this is a bug in encfs rather than in rsync? I
appreciate newer rsync might have changed behaviour, but ultimately
encfs needs to provide a regular (if virtual) filesystem. Where it
doesn't, rsync can't be expected to work.
Is there any specific reason to think that encfs is
Hi Christian and thank you for answer.
As you said --ignore-errors could work, but il would be very very
dangerous.
I had tried --exclude=PATTERN (more precisely
--filter "- /home/claude/Documents_chiffres/") and it seemed to work
better because there's not more the "IO error encountered --
I'm marking this incomplete waiting for feedback on the suggested
options or a discussion why this really should be an error to be fixed
in the source (instead of configuration).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
Hi,
I'm not 100% sure but to me that is a setup and configuration issue with the
new version being a bit more insisting that it can read/access paths it is
supposed to back up.
The new behavior can be disabled with --ignore-errors, but I'm tempted
to consider this dangerous as you could have
19 matches
Mail list logo
