Sync resulted in zero sized pdf file

superkeyor commented 8 months ago

Abstract

Sync with ios resulted in the production of zero-sized pdf file.

Expected behaviour

Everything synchronised correctly

Actually happened

a pdf of zero byte replaces old correct pdf file

Reproducing procedure

On desktop (obsidian v1.4.6, livesync v0.20.6), rebuild local and remote database with local files
Delete/Reinstall Obsidian (1.4.6) in ios
Setup livesync by paste configuration (v2 or v1 api both produce the same issue)
Restore all files from remote database.
PDF attachment whose original file size is around 10M will become 0 byte.

superkeyor commented 8 months ago

Well, the issue seems to also exist in v0.19.26

11/5/2023, 2:02:36 PM->DB -> STORAGE (modify,newnote) xxx.pdf 11/5/2023, 2:02:36 PM->Applied xxx.pdf (xxx.pdf:3-1ad06ee897134e1a867296afbe95c4bf) change...

vrtmrz commented 7 months ago

Sorry for being late! However, I have not met this problem yet. May I ask some?

Is the PDF which will be broken while synchronisation always the same?
This has been caused only while restoring? Or also in a usual synchronisation?
How about on the other platform?

superkeyor commented 7 months ago

Hi,

Thanks for your response.

1) Yes, this does not happen to every PDF, only to a couple of PDF attachments I had. It seems to the same set of "problematic" PDFs. I tried a couple of times to reset. Time 1, PDF A corrupted. Time 2, PDF A & B corrupted.

2) After it happens, I had to manually replace the 0-sized PDF with the normal copy I backed up elsewhere. Then things look normal.

3) I tested with Windows Desktop and iOS versions mentioned above. Not sure about other platforms.

Hope that could provide some useful feedback to help you find out the problems.

Thanks very much for your contribution to the community.

side note: I have been using this plugin for a while, but only happened to realize the issue recently. I have many files in my obsidian vault, so I then wrote a script to detect the 0-sized pdfs quickly and systematically.

vrtmrz commented 7 months ago

Thank you for your testing! For the time being, we are glad that it is not all files. However, it might need your help a bit more.

Could you enable the verbose log and check how many chunks are made when the (Not corrupted) PDF A has been saved? It could be shown in the log like: Content saved:test1.pdf ,chunks: 8 (new:0, skip:16, cache:8) (skip is counted in double if cached. It is a normal behaviour). If it is 0 or 1, something has gotten weird while splitting a large document.

side note: I have been using this plugin for a while, but only happened to realize the issue recently. I have many files in my obsidian vault, so I then wrote a script to detect the 0-sized pdfs quickly and systematically.

I think you are really great, thank you very much. If you found a PDF of the sort that you could show me in that process, would you mind if I ask you to email it to me? Since I have not reproduced this issue yet...

vrtmrz commented 7 months ago

Sorry for being late to notify this! This has been happening for a combination of reasons. The first reason is the same as #308. On mobile platforms, the binary file that had been split into many chunks had been fat in proportion to the number of chunks. The second reason is a result of the first problem. The enlarged file sometimes hangs Obsidian, or file accessing might be not in straight order. Therefore, the file could have been stored in the local database at unexpected times. It usually reads as zero bytes.

Therefore, now files are accessed exclusively for each, in addition to #308.

Would you mind if I ask you to check the behaviour of v0.21.2, please?

superkeyor commented 7 months ago

Wow, thank you so much for narrowing it down and for fixing the problem! I would definitely give new version a try. Thank you again for your selfless contribution to the community!

On Tue, Nov 28, 2023 at 8:41 PM vorotamoroz @.***> wrote:

Sorry for being late to notify this! This has been happening for a combination of reasons. The first reason is the same as #308 https://github.com/vrtmrz/obsidian-livesync/issues/308. On mobile platforms, the binary file that had been split into many chunks had been fat in proportion to the number of chunks. The second reason is a result of the first problem. The enlarged file sometimes hangs Obsidian, or file accessing might be not in straight order. Therefore, the file could have been stored in the local database at unexpected times. It usually reads as zero bytes.

Therefore, now files are accessed exclusively for each, in addition to

308 https://github.com/vrtmrz/obsidian-livesync/issues/308.

Would you mind if I ask you to check the behaviour of v0.21.2, please?

— Reply to this email directly, view it on GitHub https://github.com/vrtmrz/obsidian-livesync/issues/318#issuecomment-1831121631, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6UUQY6HZQ4RTPJGV333MTYG2OEFAVCNFSM6AAAAAA66AHRMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZRGEZDCNRTGE . You are receiving this because you authored the thread.Message ID: @.***>

vrtmrz / obsidian-livesync