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

Unable to relocate staged file across filesystem boundaries #15

Closed
wid opened this issue Jan 23, 2017 · 5 comments
Closed

Unable to relocate staged file across filesystem boundaries #15

wid opened this issue Jan 23, 2017 · 5 comments
Assignees
Labels

Comments

@wid
Copy link

wid commented Jan 23, 2017

When home directory and sync target directory are not on the same filesystem I get the following errors:

logs/.gitkeep: unable to create file: unable to relocate staged file: rename /home/app/.mutagen/staging/ea88434f-e8f5-43de-990f-a56e096829dd_beta/da/04c7f074f9aa5225293b4e32936e01d38b50eb90_false_da39a3ee5e6b4b0d3255bfef95601890afd80709 /data/logs/.gitkeep: invalid cross-device link
@xenoscopic
Copy link
Member

Thanks for reporting this. Sorry I've been slow to respond, I've been traveling until just recently.

This is definitely a bug and something that needs to be fixed, especially since this is a common setup on shared Linux systems.

Utilities like mv will detect this particular error and just do a copy/remove in that case, but since we need to stage the file first and then want the illusion of atomicity, it'll take a bit of thinking about exactly where the file should be relocated before being renamed into place. I'm thinking maybe it could be copied alongside its target first (perhaps with a . prefix and UUID suffix) and then renamed into place.

I'm hesitant to stage directly into the synchronization root because it could leave a lot of garbage sitting around. It's easier to have a staging directory that can be wiped after each successful synchronization cycle.

I'll investigate potential solutions and aim to have something done later this week. Probably doing whatever Unison does is the "right" thing to do, though at first glance it seems to just call down to the System.rename function, so I'm not sure it's handling this case.

@xenoscopic xenoscopic self-assigned this Jan 31, 2017
@xenoscopic xenoscopic added the bug label Jan 31, 2017
@xenoscopic xenoscopic changed the title Unable to relocate staged file Unable to relocate staged file across filesystem boundaries Jan 31, 2017
@wid
Copy link
Author

wid commented Feb 24, 2017

Hi,
Do you have update on this one ?

@xenoscopic
Copy link
Member

Hey, not just yet, but it's at the top of the priority queue. Life's just been a bit hectic until this week. I've just updated everything to take advantage of some new Go 1.8 features, and so far the performance seems a bit better just by virtue of the new 1.8 toolchain (probably due to the SSA and GC improvements). I'm not sure I'll get around to fixing this tonight, but I want it done ASAP.

@xenoscopic
Copy link
Member

I've just opened pull request #18 which should fix this. CI builds are running and I still need to test this on Windows, but I should be able to put out version 0.1.1 this weekend to fix this. Thanks for your patience!

@xenoscopic
Copy link
Member

This should be fixed by #18. I'll do a release (v0.1.1) later this weekend with this change. I've closed for now, but please re-open if this does not resolve the issue.

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

No branches or pull requests

2 participants