[Bug]: In version 0.4.47, the synchronized date and time have not changed

[YIRU69]

What happened?

In version 0.4.47, I have completed the pass-through; the synchronized date and time have not changed.

Through debugging, I saw that the synchronization information was successful, but the time on the status bar did not update.

What OS are you using?

Windows

What remote cloud services are you using?

S3

Version of the plugin

0.4.47

Version of Obsidian

1.5.10

Using password or not

• [X] Yes.

Ensure no sensitive information

• [X] I ensure that no sensitive information is submitted in the issue.

[YIRU69]

To provide additional information, I have two libraries. One of them has no problems, but the one I demonstrated has this issue. As you can see, its original synchronization time was today, but after updating the plugin and then carrying out the pass-through, it changed to 3 days. I'm not sure what the specific problem is, because it doesn't look normal.

[kadisonm]

Noticing this too. I believe the plugin is failing to get the last modified time from the remote and so it's not updating the last synced. I'll look into it.

[YIRU69]

Through testing, I confirmed that the synchronization is proceeding normally; it's just that the displayed status information is incorrect.

[kadisonm]

I had a look and to me it looks like there are multiple metadata files on my remote. It looks like it's getting the metadata time from the wrong file for me.

Managed to fix it by resetting my metadata file, since it deletes all instances of the files.

@sboesen is there a second one for a reason? If not I'll make a PR that deletes the metadata file with the oldest last synced if multiple are found.

Edit: This would be bad since getting the metadata for syncing loops through the remote files and returns the first item it finds with the default metadata file name. Plugin could be uploading to the wrong metadata file or switching between them, not sure what order it loops through the remote files.

Might refactor how it gets the metadata file and make it consistent between deleting, updating and getting last synced. And make it delete second instances that are older.

[kadisonm]

Managed to replicate this again when resetting metadata. Will implement keeping only the newest metadata file and deleting the others.

[sboesen]

That would be great, super appreciated! Our delete metadata function should do this too, right?

[kadisonm]

Our delete metadata function should do this too, right?

I think it is the cause of it. It's somehow making 2 metadata files in the Dropbox, and then when I reset again it deletes both. Might have something to do with other devices?

[sboesen]

Interesting - and it's always making two? If this is the case the number of files will go up each time we delete metadata (if I understand correctly)...

[kadisonm]

I'll have to take a look. I just noticed that after i reset the metadata the last synced wasn't correct. I then found two metadata files, which deleted correctly after reseting the metadata again.

Kind of odd but I'm sure there's a logical cause somewhere if we stepped through it properly.

[kadisonm]

Hi, this should be fixed in 0.4.49 when #135 is merged. Please try syncing again to fix it.

Thanks for reporting the issue!

[sboesen]

@YIRU69 Is this issue still occurring for you?