Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slave's symlinks deleted on sync #50

Open
jordan-stone opened this issue Mar 18, 2014 · 4 comments
Open

slave's symlinks deleted on sync #50

jordan-stone opened this issue Mar 18, 2014 · 4 comments

Comments

@jordan-stone
Copy link

I've been using bitpocket for a while with great success. I can't seem to track down why
soft links created on my slave machine are deleted when I run a sync. I saw a note referencing a missing RSYNC_OPTS bug so I downloaded the most recent version to test if it fixes the problem. It does not.

@ku1ik
Copy link
Owner

ku1ik commented Mar 18, 2014

I have just merged mentioned PR. Please check latest version from master.

@jordan-stone
Copy link
Author

Thanks. I just checked the latest version which does now behave differently. Specifically, now when I set the RSYNC_OPTS="-L" parameter my slave-side soft links aren't deleted. However, I'd really prefer to have RSYNC_OPTS="-l", so that my links are copied as links, not dereferenced. When I set RSYNC_OPTS="-l" in the config file, bitpocket returns to the old behavior of deleting the links on the slave side.

@jordan-stone
Copy link
Author

I think I've tracked down what's going on. When tree-current is being built with the rsync call on lines 128 and 129, even though rsync is called with the -a switch, the following grep selects only normal files and directories. So, unless the -L switch is set, new links never make it into tree-current and are deleted during the fetch.

One change I can think of which could solve this problem is the following: change the grep call from grep "^-|^d" to grep "^-|^d|^l" and then append an additional pipe to another sed call to get rid of the arrows associated with links, something like sed "s:->.*::"

I don't think I completely understand what all the implications of such a change would be, or if there is some reason why this would be a bad idea. Any thoughts?

@greezybacon
Copy link
Collaborator

@jordan-stone I believe this was addressed in 33b61a8, would you mind pulling and trying with the new codebase?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants