[rdiff-backup-users] Python 3 migration: considering non-UTF-8 conform filenames

Hi, as I worked on migrating to Python 3, one of the "fanciest" aspects was the change from str/unicode to bytes/str "character chains" types. Without going into the technical details (python savvy persons will know what I mean), it means among other things that the codeset of file names becomes

Re: [rdiff-backup-users] Python 3 migration: considering non-UTF-8 conform filenames

Hi, On 03/08/2019 14:50, Robert Nichols wrote: >> The way to work around this in rdiffweb at least it's to manage path as >> bytes. That is how rdiffweb 1.2.8 is working. Path are bytes. That is >> also >> how most filesystem are working too. Paths are bytes and those are >> decoded >> to be

Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

On 04/08/2019 14:46, rhkra...@gmail.com wrote: > I added the below --was it intended that there be some content in > this message? If so, I don't see it. > > (The reason I bring this up is that, over on the Debian user list, someone > was > sort of constructing there own emails (iiuc), and

Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

rdiff-backup, thanks to Otto for kicking this! Eric On 27/07/2019 01:17, Eric L. wrote: > Hi, > > I've just finished the migration of rdiff-backup to Python 3 after months of > work, improving at the same time the test framework. Anybody can check and > feedback at https://github

Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

Hi Graeme, me (?), others, On 27/07/2019 10:52, Graeme Robinson wrote: > I echo the goodwill from users of rdiff-backup like myself. I would > be lost without it! Its still the primary backup tool for 90% of my > servers. > I too would be happy to help with testing. I've just added a few notes

Re: [rdiff-backup-users] Future of rdiff-backup: Python 3 migration and project maintainership in general

Hi, I've just finished the migration of rdiff-backup to Python 3 after months of work, improving at the same time the test framework. Anybody can check and feedback at https://github.com/sol1/rdiff-backup/pull/40 without paying money The quality seems equal to the version 1.2.8 packaged under

Re: [rdiff-backup-users] Python 3 migration: considering non-UTF-8 conform filenames

Hi, On 04/08/2019 08:59, Eric L. wrote: > OK, I've created a sub-branch ericzolf-py2to3-bytes and will work on > this aspect, moving away from str for paths to bytes. If someone is interested, there is a working version at https://github.com/ericzolf/rdiff-backup/tree/ericzolf-py2to3-byte

Re: Pre-release v1.9.1b0 - 3rd beta release before 2.0.0

Hi again, one last word: I'd like to shoot for a release in two weeks, meaning 8th of March, unless there is a (very) good reason to slip it further. Hope this fits everybody's timeline. KR, Eric On 23/02/2020 10:33, Eric L. wrote: > Hi, > > sorry, I forgot to say but the versio

Re: Backward compatibility of next beta

Hi, On 04/02/2020 14:58, Patrik Dufresne wrote: > I'm definitely looking toward a similar solution where it's seamless. > The more I'm thinking of it, we may need to change the code in > rdiff-backup to help us. What would really help is having rdiff-backup > calling a different executable in the

rdiff-backup pre-release v1.9.0b0 - Second beta before 2.0.0

Hello everybody, We've fixed a few bugs under Windows, worked a lot on the documentation and our build process, offering new formats to install. Please try it and give us feedback on the mailing list. The README should explain how to install which format, if not, let us know. Enjoy, Eric —

Re: using --remove-older-than takes a very long time?

Hi Derek, On 07/02/2020 14:46, Derek Atkins wrote: > HI, > > I've been running backups on my servers for a long time using > rdiff-backup. My backup server has been offline for about a week and I > just put it back online yesterday. The server does the following: > > foreach host (list of

Re: Last call before release of rdiff-backup 2.0.0

Hi, as a further side note, test.pypi.org hold now the betas as well and as wheel (ha!), but also as source. rdiff-backup is now one pip command away (with or without --user): pip install -i https://test.pypi.org/simple/ rdiff-backup==1.9.0b1.dev8 See

Pre-release v1.9.1b0 - 3rd beta release before 2.0.0

Hi, 3rd beta release before 2.0.0 Repository: rdiff-backup/rdiff-backup · Tag: v1.9.1b0 · Commit: 3f2b56a

Re: Pre-release v1.9.1b0 - 3rd beta release before 2.0.0

10:30, Eric L. wrote: > Hi, > > 3rd beta release before 2.0.0 > <https://github.com/rdiff-backup/rdiff-backup/releases/tag/v1.9.1b0> > > Repository: rdiff-backup/rdiff-backup > <https://github.com/rdiff-backup/rdiff-backup> · Tag: v1.9.1b0 > <https://gi

Re: Exception ''<' not supported between instances of 'RPath' and 'RPath''

Hi Miroslav, the issue is known and addressed https://github.com/rdiff-backup/rdiff-backup/issues/322 If you are able to test the release candidate 2.0.1rc0 the issue should be gone. https://github.com/rdiff-backup/rdiff-backup/releases/tag/v2.0.1rc0 KR, Eric On 14.05.2020 10:02, Miroslav

Re: Issue with the man page

Hi, difficult to say without knowing what fish is looking for, and man pages are not meant to do automated auto-completion. Anyway, I can only say that the `--allow-duplicate-timestamps` option is new with 2.0.5 and might be the reason for the issue. This said, I don't see anything

Weekly release of rdiff-backup

Hi, I just wanted to announce that we have now weekly releases. They are available always under the same tag at https://github.com/rdiff-backup/rdiff-backup/releases/tag/weekly And they are (re-)generated each night from Sunday to Monday at 22:22 UTC. They are not meant for production

Re: Backups not working after running out of space

Hi, too late for Peter's issue, but I created an example on how to avoid the issue (or at least reduce the risk): https://github.com/rdiff-backup/rdiff-backup/pull/947 Review welcome. BTW, check also

Re: Doubled dates in old repositories

Hi Dominic, On 20/04/2020 08:40, Dominic Raferd wrote: > I have checked our 108 repositories which go back a long way (I am still > using v1.2.8). I find this issue in one repository for some 27 dates > (mostly but not all consecutive) in January and February 2009. They are > almost (but not

Doubled dates in old repositories

Hi, we've got a report for an issue [322] where we're not sure how it happened and if it happens often. As I know that some of you have many and long standing repos, you might want to have a look before you upgrade to 2.0.0. Also I'd like to know if the problem is unique (manual intervention

Re: Doubled dates in old repositories

Hi, On 21/04/2020 13:46, Dominic Raferd wrote: > Despite the failed verifications, I have successfully recovered a largish > (>150MB) file from December 2008 in the impacted repository. As there are > 2806 later versions of this file (with changes in this file occurring > between most of these

Re: rdiff-backup 2.0.0 crashed the first time I ran it

Hi Walt, no issue, we all have our terse days ;-) The error is known and already fixed in the repo: https://github.com/rdiff-backup/rdiff-backup/issues/310 Next release (no due date yet) will have the fix. KR, Eric On 29/04/2020 21:45, Walt Mankowski wrote: > Hi everyone, > > First I'd like

Pre-release v2.0.1rc0

Hello everybody, We're planning a fix-only release and this is the first release candidate to allow anybody to test this release, all details in the change log . Please focus your tests on the interdependency (with 2.0.0) and remote aspects, which are especially difficult to test automatically.

Re: We need more Pull Requests reviewer

on the project and I can't afford to review the > PR in a timely manner all the time. I understand it can be frustrating > for you and I am open to suggestions. > > For the time being, I will continue reviewing the PR when I have a chance. > > > On Thu, Aug 6, 2020 at 1:47 AM Eric

Re: We need more Pull Requests reviewer

Hi, On 17/08/2020 20:02, rhkra...@gmail.com wrote: > On Monday, August 17, 2020 01:43:51 PM Patrik Dufresne wrote: >>> as the subject says, pull requests can stay for days without review, and >>> I really don't like merging my own PRs without someone having looked >>> over it. >>> >>> Reviewing

API versioning and backward compatibility discussion

Hello, Patrik and I are discussing the new API versioning scheme we're trying to put in place to make sure we don't introduce incompatibilities in the client/server connection in an uncontrolled manner, like we did between v1.x and v2.x. If you are interested, the discussion is taking place in

We need more Pull Requests reviewer

Hi, as the subject says, pull requests can stay for days without review, and I really don't like merging my own PRs without someone having looked over it. Reviewing documentation doesn't require any specific knowledge even if being a native English speaker might be an advantage :-) Just tell the

Pre-release v2.0.4rc0 - Bug-fix release candidate 2.0.4rc0

Hello everybody, as described below, here is the first step to the last bug fix release for the 2.0.0 branch (as far as I can foresee it), all other bug fixes require first a bit more work on the overall code, hence they'll happen later. The bits can also simply be installed from

Question around of remote description

Hi, in the course of the review of PR #404 we came to challenge the quite complex quoting rules allowed when you backup to/from a remote location. Our question is if anybody is relying on those (too) complex quoting rules to make their backup work? Else it'll allow us to radically simplify the

Re: Question around of remote description

Hi, once again thanks for the all the good feedback. As said, we keep the complicated pattern matching for the description, allowing to escape colons. Thanks, Eric On 18/06/2020 05:20, Robert Nichols wrote: > On 6/17/20 1:15 AM, Eric L. Zolf wrote: >> Hi, >> >> in the cours

Re: Discussion about file format for the future

Hi, to close this discussion, I've created an enhancement request #399 but don't hold your breath, it's not yet on the priority list. KR, Eric https://github.com/rdiff-backup/rdiff-backup/issues/399 On 09/06/2020 22:51, rhkra...@gmail.com wrote: > On Tuesday, June 09, 2020 12:30:24 PM Robert

Re: Obsolescence Python 3.5 support plan

Hi Derek, On 09/06/2020 16:24, Derek Atkins wrote: > EricZolf writes: > >> Actually, while writing this e-mail, I checked the code and noticed that >> it's enforcing pickle version 1 so the issue isn't the pickle protocol, >> the issue is solely the bytes vs. str vs. unicode change between

Re: Discussion about file format for the future

Hi, that's an interesting idea, I was more in the optic of keeping a simple file based structure but if there are requirements, we can think about alternatives, it could be a SQL or even a noSQL DB, or a keystore. Regarding the terabytes of data, I take the point, I never foresaw to convert the

Release v2.0.5 - Last bug-fix before code clean-up

Hello everybody, without further comments, let's party! KR, Eric Last bug-fix before code clean-up Repository: rdiff-backup/rdiff-backup · Tag: v2.0.5

Ansible collection to automatically install rdiff-backup

Hi, as some of you have signaled that they have large deployments of rdiff-backup, an automated way to deploy rdiff-backup might be useful. It can also hide some of the complexity of the installation, once it's been fine tuned. The collection can be grabbed from:

Re: no-hard-link for a simple mv wrapper

Hi, the man page is misleading: without `--no-hard-links`, rdiff-backup does its best to keep hard links (i.e. stores them under same inode), but _with_ this option, it actually treats them as two different files, and stores them under different inodes, actually duplicating the disk space

Feedback required - new arguments parsing for rdiff-backup

Hello everybody, first, let me wish you a happy new year, health and good luck. I'm currently working on using argparse to improve the way command line arguments are parsed, in a way compatible with the old handling while developing a new, hopefully more logical and easier to extend,

Re: How to show errors?

Hi Brian, normally, each repository, under rdiff-backup-data, contains a backup.log and dated error_log files, where you can find details, depending on the verbosity you've chosen. Hope this helps, Eric On 02/02/2021 13:55, Brian Bouterse wrote: I read the man pages and faqs but I didn't

Re: too many lstat() syscalls, therefore too many IOPS

Hi, first, I don't see anything surprising in what you describe, so all normal AFAICJ. Second, rdiff-backup needs to check each source file/directory and each target, compare them and then copy (or not), so if you have some 2300 files to backup, that would sound about right. If the target

Re: progress bar?

Hi, On 14/05/2021 09:29, griffin tucker wrote: i can try drafting some pseudo-code, but by the looks of things, it'd take some major restructuring - not impossible, though! I never said that it's impossible, but "major restructuring" is indeed in progress, and "not very difficult" is

Re: too many lstat() syscalls, therefore too many IOPS

Hi, first, I don't see anything surprising in what you describe, so all normal AFAICJ. Second, rdiff-backup needs to check each source file/directory and each target, compare them and then copy (or not), so if you have some 2300 files to backup, that would sound about right. If the target

Re: too many lstat() syscalls, therefore too many IOPS

on. On Thu, 13 May 2021 at 03:08, Eric L. Zolf wrote: Hi, first, I don't see anything surprising in what you describe, so all normal AFAICJ. Second, rdiff-backup needs to check each source file/directory and each target, compare them and then copy (or not), so if you have some 2300 files to backup

Re: what to do if --check-destination-dir ends in traceback?

Hi, the version 2.0.5 won't help here IMHO, there are two issues: 1. the "Unknown field" errors hint at the fact that the file system issue has corrupted the metadata of the repository. This will be difficult to impossible to fix, more on this later. 2. the traceback is actually due to an

Re: Two more documentation pull requests to review

Already one week passed, and not one single review... Open Source is a bit like Democracy in this that it doesn't work if people don't participate. Nobody should be surprised if development stalls... Thanks for your support, Eric On 26/02/2021 09:58, EricZolf wrote: Hi, as the subject

Re: Please help the rdiff-backup project by reviewing pull requests (not a hard thing to do!)

Hi, so, if someone wants to help and isn't yet subscribed, there is a new Pull Request to review: https://github.com/rdiff-backup/rdiff-backup/pull/535 It's half (architecture) documentation and half code, with the focus of the clarity of the new action plugin interface. Thanks, Eric On

Re: Does anybody have any use of error_log?

Hi, On 07/04/2021 14:05, Patrik Dufresne wrote: Hello Eric, Thanks for asking ! To give you a recent example. A new customer of mine has an error with it's backup and the following lines get added to error_log. ListError

Re: win_acls changes trigger creation of increments

Hi, On 22/04/2021 05:15, Robert Nichols wrote: On 4/21/21 12:08 PM, Patrik Dufresne wrote: [snip] 1. I'm not aware of any changes in the logic between 1.2.8 and 2.0.5 regarding Win_acls. So I'm expecting this to be an issue in 2.0.5. Is it ? 2. Would we consider this normal behavior to

Re: Pall Requests waiting for review

Hi, a friend of mine did review the easiest PRs, but there is still one big PR pending review, blocking me: https://github.com/rdiff-backup/rdiff-backup/pull/614 Thanks, Eric On 06/09/2021 22:07, EricZolf wrote: > Hi, > > I don't want to sound like a broken record but there are 4 pull

Lack of reviewers (again) and decision

Hi, I don't want to sound like a broken record but I have again a pull request [1] waiting for review and nobody takes care. Our contribution guide states that "Ideally each pull request gets some feedback within 24 hours from it having been filed" and we're far from it. I'm also tired of

Re: cross-platform backup tool Lack of reviewers (again) and decision

ers, I took a look at > the PRs, but couldn't decide anything about them as I lack knowledge of > the implementation. > > I "watch" the repo now and try to find some time to look at the code > such that in the future I might be somehow more helpful for this project :) > >

Re: Trouble running rdiff-backup after Windows updates

Hi Michael, it's difficult to tell without a more concrete error message. Running the command in debug mode (-v 9) might help to understand where the script hangs. What happens if you call `ssh ${BACKUP_USER}@${TARGETHOST} rdiff-backup.bat ${BACKUPTO}` like the cron job? Or even something like

Re: cross-platform backup tool Usage of the

Hi, On 11/12/2021 17:33, Patrik Dufresne wrote: > I would recommend to remove the ability to change the quoting, but would > move the feature into a migration action that would update the quoting on > existing repository. Similar to the deletion operation. I like very much the idea. This would

cross-platform backup tool Usage of the

Hi, while refactoring the code, I stumbled upon the (theoretical) possibility to change the quoting used in the repo with the option --override-chars-to-quote (i.e. replace the characters not allowed on the target filesystem of the repo with some code). According to my analysis, the option never

Re: BackupFriend - new desktop application that uses rdiff-backup, all open source

Hi, On 21/07/2021 04:07, Guy Sheffer wrote: BTW two feature requests I got were encryption and no history, only rsync-like behavior. I wonder if building something that handles multiple backends might be a more general solution (as much as I like rdiff-backup). As much as I like rdiff-backup