Code-settings-sync: Extension always asks to enable Force Upload

Created on 21 Aug 2019  路  5Comments  路  Source: shanalikhan/code-settings-sync

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).

bug 馃悰 fixed

Most helpful comment

lastUpload seems to be correct but it's saved in UTC while I'm on a different time zone (+3).

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 forceUpload, which is bad.

Consider:

  • Machine A uploads settings to make revision 5 in the gist.
  • Later, Machine B downloads, makes a change, and (force) uploads settings to make revision 6 in the gist.
  • Later, Machine A downloads revision 6 and makes a change and tries to upload.

The upload fails because Machine A's lastUpload has the timestamp of revision 5, and the gist is on revision 6. The current code considers the gist as "newer" if gistLastUpload >= localLastUpload.

Machine A's lastDownload is for revision 6 and so it seems that the local lastDownload should be compared to the gist's lastUpload to determine if the local machine has the latest gist content.

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 forceUpload is false and either of these is true:

  • localLastDownload is < gistLastUpload
  • none of the files have been changed (#316)

(I'm not sure if forceUpload overrides both of the above or not - but just keep it the way it is now.)

All 5 comments

lastUpload seems to be correct but it's saved in UTC while I'm on a different time zone (+3).

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 forceUpload, which is bad.

Consider:

  • Machine A uploads settings to make revision 5 in the gist.
  • Later, Machine B downloads, makes a change, and (force) uploads settings to make revision 6 in the gist.
  • Later, Machine A downloads revision 6 and makes a change and tries to upload.

The upload fails because Machine A's lastUpload has the timestamp of revision 5, and the gist is on revision 6. The current code considers the gist as "newer" if gistLastUpload >= localLastUpload.

Machine A's lastDownload is for revision 6 and so it seems that the local lastDownload should be compared to the gist's lastUpload to determine if the local machine has the latest gist content.

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 forceUpload is false and either of these is true:

  • localLastDownload is < gistLastUpload
  • none of the files have been changed (#316)

(I'm not sure if forceUpload overrides both of the above or not - but just keep it the way it is now.)

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:

Sync: Gist has a newer or identical version of your settings. Do you want to enable forceUpload to override this?

At this point, I think it would be the easiest to revert #923 and implement it again, with the feedback from here and #1035.

v3.4.3 Released. Let me know if there is any problem :)

@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

Was this page helpful?
0 / 5 - 0 ratings