-
Notifications
You must be signed in to change notification settings - Fork 510
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
Filesystem mismatch, leading to sync creation failure #2680
Comments
I'm on Arch Linux and I often encounter this issue when Arch is updated. On next restart it will surely show this mismatch issue. Does this make sense with the current discovery you made? I hope your fix will be reviewed by the MEGA team. They almost don't look at this repo. Maybe they do look at pulls, but they don't collaborate. They just upload their latest code without closing issues/pulls. |
Maybe, maybe not. What you are describing looks very much like the issue I am proposing a fix for. But another user reported a problem with the same error message (filesystem mismatch) but with slightly different logs. That makes me wonder if maybe there could be more than one bug in this part of the code. But I didn't notice anything obvious. If you want to help me investigate further you can check this report. Please post your logs just like he did and try to compile and run the test code I posted there (you will have to change the path in the main() function). If the test code successfully detect the device the path is on then my fix will work for you. If not that means there is another issue. There is activity of this repo. I opened a case with MEGA support and I sent them my report. They said they forwarded it to the devs so, at least, they should know about it. |
Hey @ChiwTheNeko, Nice analysis and bug hunting! You have indeed caught and identified a bug :) I'm the author of this code and I'm sorry to have caused you and others any inconvenience: We've been fighting some issues around the "filesystem fingerprinting" code for quite some time due to the unreliability of the legacy filesystem fingerprinting mechanism. It's been difficult for us to fix in a clean way without pulling in other dependencies which we cannot support on all the targets that we build for. It seems the bug you've found simply slipped through review: We'll jump on that, ASAP. Thanks again for your time and analysis. |
Hey @ChiwTheNeko, I've created a ticket here in our bug system to fix the issue: my manager will assign someone to fix it shortly. There are two versions of the same bug that you've found: The one you found on line 2186 and another on line 2309. If you're able to build locally or if you're just curious, one way to solve the issue would be to use a different overload of find. Instead of:
Use
Instead. Hopefully the issue will be closed soon and you guys will be away syncing again in no time. |
UPDATE: In version 5.4 this issue seemed fixed already. I don't experience the mismatch even after the package updates. Will still observe if it recurs. |
I'm still having the problem. |
Sometimes the MEGASync app will fail to restart sync and dump an error saying "Local filesystem mismatch". Removing and re adding the sync will fix the issue but only until the computer reboot. After reboot the problem may appear again.
The logs contains the following:
The logs shows that MEGASync failed to identify the device the sync is on. The sync /home/nicolas/Pictures is not on device / but on /dev/sda1. This miss identification of device cause MEGASync to fallback to the unreliable legacy filesystem fingerprint system. The legacy fingerprints are not persistent across reboot which lead to the "Local filesystem mismatch" error.
After investigation the problem appears to be into function
static std::string deviceOf(const std::string& database, const std::string& path)
in filesrc/posicx/fs.cpp
.At line 2172 the code execute
realpath(device.c_str(), storage.data())
which check if the device is a symlink and store the real path into the stringstorage
. Butstorage
may already contains some data that is longer than the string stored byrealpath()
.Therefore, at line 2186, the code attempts to trim
storage
to the first null character.This line appears to be the problem. With these parameters
storage.erase
will only erase one character fromstorage
, not the entire end of the string. As a resultstorage
will be something likeProposed fix would be to replace line 2186 by the following:
That way the
storage
will be properly trimmed.Note
This problem has already been reported on the MEGASync project. See:
meganz/MEGAsync#964
meganz/MEGAsync#844
meganz/MEGAsync#947
I believe all of these are the same problem, but the issue should have been reported on the sdk instead.
The text was updated successfully, but these errors were encountered: