What's the file size limit for an attachment in Android? #2146

  • The version you are using. 1.0.311
  • The operating system you are using. Android
  • The sync method you are using. WebDav
  • Are you using encryption?. No

Hi,

I attached a pdf of 44mb and when I sync in Android it says something like ‘resource not available for [id].md’ but i synced from another laptop and it worked perfectly. Small files around 3-4mb work nice.

Any help?

It all depends on several factors:

If you use encryption, the limit is 10MB.
If you use OneDrive, the limit is 4MB.

Other than that I’m not aware of any limits, so I hope that somebody else has a better answer. More info might help other to answer the question (what sync target are you using, encryption on/off).

Im using webdav and no encryption.

Thank you, I just updated the question.

For mobile, the limit is 10MB even without encryption actually. The lib we use for fetching files will crash the app when downloading large files.

wow, really? that’s sad because I attach a lot of pdfs and documents higher than 10mb :S
are there any plans to update the file size limit? maybe switching to another library?

Eventually, yes, I hope to switch to a better library, but not sure when.

1 Like

Just installed Joplin, set up WBDAV sync with my OwnCloud server, and am very excited to have an alternative to Evernote (which I have used for over 10 years, generating thousands of notes). However, the crash on mobile caused by the 10MB limit is a show-stopper for me, since it also apparently prevents my other notes (with attachments under 10MB) from syncing.
Would it be possible as a temporary work-around, to have the mobile app first check the file size, and not attempt to upload when it would cause a crash? Obviously, the long-term solution is to fix the 10MB limit, but if this will take a while, at least preventing the crash would enable me (and others migrating notes with such attachments) to use your well-developed product. Thanks!

Did this limit recently change? I remember having the issue previously, but today am able to open an 18MB attachment on Android that I added on macOS (v1.0.201).

I think the limit is still there.
What sync method are you using? And do you have encryption enabled?

I don’t think it has been changed, nothing on the release logs, and I guess that laurent would have said something.

Now it allows any size of resource, but will add a warning in the log if you upload a resource larger than 10MB. There are other mechanisms in place to prevent the app from crashing on certain devices when downloading large attachments (namely it gives up downloading if it made the app crash more than twice).

1 Like

Wauw, that looks sophisticated now :slight_smile: Thanks!!!

Is this a recent change?

It reminds me of these 2 issues: https://github.com/laurent22/joplin/issues/2424 & https://github.com/laurent22/joplin/issues/2943 where both users mention they have large files (around 50 mb).

I tried to reproduces this over the weekend and could not get mobile app to sync large files.

Ok I think I got confused as we have several different checks for out of memory issues. The one I had in mind is the one to handle decryption crashes, which are hard to prevent, so if it crashes more than twice the data won’t be decrypted again:

https://github.com/laurent22/joplin/blob/d2acf314f57cbea2942faa568f53bb74abb94add/ReactNativeClient/lib/services/DecryptionWorker.js#L171

The other check in on the synchronizer: it will indeed still refuse to download resources that are larger than 10MB on mobile:

https://github.com/laurent22/joplin/blob/d2acf314f57cbea2942faa568f53bb74abb94add/ReactNativeClient/lib/synchronizer.js#L724

And the issues you mentioned above, we don’t currently handle. It’s the fetching lib we uses that crashes for large resources on older devices. I guess the same logic as for decryption should be applied - if it fails more than twice, stop trying.

I’ll look into this. I think it does some serialization to push data over RN bridge somewhere where it’s not really needed.

Exactly. But I had a look at it at some point and couldn’t find how to prevent it from doing this unnecessary serialization. Maybe the package has been improved since then and there’s a way now.

Dropbox. With encryption enabled.

It’s interesting that the other users who said they had the app crash (supposedly due to a large attachment) were all using dropbox with encryption enabled.

I had a suspicion that there might be a bug here and I think I’ve found it: https://github.com/laurent22/joplin/issues/3107