ynikitenko / yarsync Goto Github PK

rsync key --ignore-existing seems to conflict with -H (hard links). Filed an issue for rsync, got no reply yet.
If this doesn't get fixed (or suggested how to fix that in yarsync), then ignoring existing files will not work. This is a nice security feature, it was introduced right before the 0.1 release.

At the moment, use --overwrite key during yarsync pull/push. Alternatively, use the hardlink executable afterwards (doesn't always work; in this case remove new commits and re-synchronize with --ignore-existing).
clone, commit and other commands work fine, because --ignore-existing is used only in pull/push.

Version

yarsync version 0.2.1
python3.11

Operating System

macos ventura and archlinux

How to reproduce

mkdir repo
cd repo
yarsync init
yarsync commit -m "Initial commit"
echo 'test' > test
yarsync commit -m "test commit"

Then we try to get the commit id

$ yarsync log
No synchronization directory found.
No synchronization information found.
commit 1699541234
test commit

...

triggering crash

yarsync show 1699541234

output and traceback

No synchronization directory found.
No synchronization information found.
Traceback (most recent call last):
  File "/usr/bin/yarsync", line 33, in <module>
    sys.exit(load_entry_point('yarsync==0.2.1', 'console_scripts', 'yarsync')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/yarsync/yarsync.py", line 2857, in main
    returncode = ys()
                 ^^^^
  File "/usr/lib/python3.11/site-packages/yarsync/yarsync.py", line 2807, in __call__
    returncode = self._func()
                 ^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/yarsync/yarsync.py", line 2573, in _show
    self._print_log(commit, log, sync)
  File "/usr/lib/python3.11/site-packages/yarsync/yarsync.py", line 2053, in _print_log
    if commit in sync.by_repos.values():
                 ^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'by_repos'

• center the top button "View On GitHub" vertically,
• create navigation between pages?
• use hacker theme instead of midnight? Decide on its readability first. At the moment fonts are unreadable. Green sections look awesome, but maybe white is less distracting and better for reading a manual?
• can't link to document sections (including manual and inter-manual links),
• can't copy code with a click (as it is done on GitHub); not essential, but nice to have,
• add an arrow "to the top of the page" at the bottom?
• manual still looks a bit better in the terminal.

Hello, I am looking for a synchronization tool similar to git but that can handle FS metadata (timestamp), and found your project that seems to be a good match. Now I am trying to evaluate whether it is suitable for my use case.

But when push, that some data that has not yet been committed will be overwritten.

Version

yarsync version 0.2.1

Operating System

macos ventura and archlinux

What happened

We have two computers A and B, create a repo, create a file1 and commit.
And make sure that A and B each have a copy of the repo.

Then modify file1 on B then push from A, we can see that the file1 has been overwritten.

How to reproduce

init repo

# on A
mkdir test1
cd test1
yarsync init
yarsync commit -m "Initial commit"
yarsync remote add my_remote host:/tmp/test1-repo

# on B
mkdir /tmp/test1-repo
cd /tmp/test1-repo
yarsync init

then push repo from A to B, and make file1 push again

# on A
yarsync push my_remote

echo testfile > file1
yarsync commit
yarsync push my_remote

Modify file1 on B

$ echo 'should not be overwritten' > file1
$ cat file1
should not be overwritten

Then push from A again, We can see that the file is overwritten

# on A
yarsync push my_remote

# on B
$ cat file1
testfile

What you think should happen instead

yarsync should detect and avoid overwriting data, shows that the remote has not yet committed.

If this is not the intended use, it must be aborted to avoid data loss.

Like make a config option that auto delete commits and log older than 1 year. Make it optional, as it looks to be bad practice for some. It will surely remove the folder house keeping burden for others, since rsync do has limitations for large number of files.

UPD: click looks good for that.

Requirements for a formatting tool:

• cross-platform (and disabled when it is not installed / supported)
• high-level (and take care to restore original colours after the exit).

Probably some other factors should also be taken into consideration. Note, that we don't need full True Colours, but rather simply enhance user experience in several small places.

These packages look good: yachalk and colorful (the latter looks more powerful, because it supports Windows and Python 2 (if we ever use that)). There is also some comparison on StackOverflow.

Formatting could be based on how git formats its output.
Volunteers are welcome! If you take on this task, let us agree on the package first.

Hi, I think it might be a useful feature if .yarsyncignore could be implemented in yarsync.

This can avoid commit and synchronize __pycache__, .DS_Store, some-program.lock, such folders and files

It seems that this feature possible implemented through --exclude-from=

Thank you

Hello,

I am running an headless server running Archlinux and wants to backup one hard drive to the other one - so it needs to copy new files but also to delete files that were removed. There is also couple of folder within the hard drive that must be ignored.

So the question is, is it possible? The plan would be to write a script that is run through cronjob.
And the second question - sorry but I couldn't find the info on the wiki page - what would the command be?

yarsync clone /mnt/hd /mnt/hd-backup ? But how to tell it to ignore a folder?

Thank you for your time.

There are some problems with the pdf version produced by Sphinx or Read the Docs.

• TOC. I could find no way to properly incorporate the manual into the document (it is either in the section "thanks", or I have to include it twice to get a dedicated toc entry).
• formatting. Some strings are formatted incorrectly. This can be due to manual formatting (it is optimised for man). Will anything be improved if we use RST instead of Markdown?
• Release notes. I would add them in a section after Advanced, but could not do it well yet.

In the README, it states "Since there is no general way to install a manual page for a Python package, one has to do it manually.". I'm not sure this is entirely accurate as the SetupTools.setup function allows for a data_files argument which provides the ability to install files to another location on the system. As this StackOverflow answer states, one could use this to install manpages. I've tested this and it works on my Arch Linux system, although I haven't tested it further than that. I'm happy to make a PR including this feature, but only if you think that this is a feature you would consider in this project.

TLDR: It may be possible to automaticly install man pages via setup.py, is it worthwhile to pursue adding this as a feature?