-
-
Notifications
You must be signed in to change notification settings - Fork 394
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
Extension always asks to enable Force Upload #1016
Comments
I don't think that this is the issue because the timestamps are in UTC in both the gist and local files. It looks like the real problem is caused by faulty logic for the "safe upload" check. As it stands, if there are multiple machines doing uploads, then any machine that did not do the last upload cannot upload unforced, even if it downloaded first. This essentially requires the use of Consider:
The upload fails because Machine A's Machine A's Indeed, this is what is seen in the "safe upload" issue proposal, but not in the current code. So, I think you want to abort the upload if
(I'm not sure if |
Downgrading extension version to 3.4.1 is helped for me. |
I thought I'm hitting a different issue in #1035 but it might be this one. For search, this is what the dialog says:
At this point, I think it would be the easiest to revert #923 and implement it again, with the feedback from here and #1035. |
* Make IsGistNewer compare against latestDownload Instead of comparing the gist's latestUpload time against the local latestUpload time, this function should compare the gist time against the local latestDownload time in order to determine if the cloud settings are newer than the local settings. Also, on an upload, set the local latestDownload time to the same time as the upload since the settings are effectively "downloaded" on an upload. This protects against the following scenario: - Machine A uploads settings to cloud - Machine B downloads these settings - Machine B changes settings and uploads them to the cloud - Machine A downloads the settings - Machine A changes settings and tries to upload them The last upload attempt fails because A's last upload time is before the cloud's last upload time, even though A downloaded the settings. A forced upload is needed in order to upload the settings. It therefore makes sense to compare against the local download time. * Fix changed files check to work with snippets When checking for the existance of files in the gist, use the settings file "gistName" to lookup the file in the gist instead of "fileName" in order to find any files in a subdir. The gist uses "|" as a separator in the "gistName" for files in a subdir and so using a plain filename does not match. This fixes the case where a user has snippets and does an upload with no changes to settings or snippets. The snippets are already up in the gist. The code that checks for files that are local and not in the gist fails to match the fileName to the gistName and incorrectly concludes that the file is not in the gist. This causes the upload code to upload all the files even if there were no changes, resulting in an "empty" gist revision with only the upload timestamp changed. * Fix uploadCancelled status bar message timeouts
|
@shanaccelirate Today my another devices installed v3.4.3, after configing gist ID & token,even turning on "forced download". But it showed the same tips: "sync:reading settings online on the botton",while vscode did nothing actually. :D |
I enabled just simple auto upload, but when I edit
settings.json
extension always says that version in Gist is newer and asks to enable force upload.BTW: VS Code language is english, so why the heck does it show up in Russian?
Enabling of
Force Auto-upload
works, but it's a non-sense, I have only 1 single VS Code instance, and just installed the extension. Gist is saved by extension.lastUpload
seems to be correct but it's saved in UTC while I'm on a different time zone (+3).The text was updated successfully, but these errors were encountered: