search

sboesen / remotely-sync

fork of remotely-save with security upgrades
Apache License 2.0
209 stars 8 forks source link

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

Open YIRU69 opened 8 months ago

YIRU69 commented 8 months ago

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.

screenshots

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

Ensure no sensitive information

YIRU69 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

kadisonm commented 8 months ago

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 commented 7 months ago

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

sboesen commented 7 months ago

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

kadisonm commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 5 months ago

@YIRU69 Is this issue still occurring for you?