Store images in Dropbox

Hello, my notes are synced with DropBox, but when I attache image in note on MacOs - it is saved in resource folder of program, why not in dropbox? can I change it?

And for sure that images are not synced with mobile and other devices :frowning:

I think, that it have to be a basic setting for resource folder :confused:

It will be stored in both, the sync is isn't a host, it is there to bring all connected clients in line with eachother so for every client set to download images you will have a copy of the resource in the resource folder (e.g on mobile you could set image download behaviour differently to a desktop client).

If you want to reference an external image then you can do that.
For example if you upload your images to a different dropbox folder you can use its URL to display the image if that is what you want:
e.g.

![joplin-picture.png](:/49e6c7b53e3f4c24ae04353830b9b93b)
![local-folder-picture.png](/home/name/dropbox/pictures/cat.png)
![dropbox-url.png](https://dropbox.com/whateverthepubliclinktocatpictureis/cat.png)

Are all valid markdown resource links to display the picture.

If you copy image in browser and input in note - it will save only in inside resource of app :frowning: Apparently this is not my scenario :frowning:

Same problem if use web clipper

That is by design, Joplin is always local data first, it saves the resources internally then syncs that resource to the sync target so that other clients can then download and use that resource in their own local data.

If you need to link to remote resources then you have to specify that within the markdown itself like in my examples, you can't import the image straight into Joplin.

Yep, but why not add setting for resource folder in local( by default it can be inside app), if so I can input Dropbox or other cloud folder in local and my resources will be synced. I think it is not big programming task but give us more freedom :slight_smile: For example Obsidian have that setting

Obsidian is a fundamentally different design though, it uses local files for literally everything as each vault is literally just a file system directory so it can just work out of the local folder.

For cloud sync targets Joplin doesn't use the local folders at all, it does it all via the online protocols (i.e. it doesn't use your filesystem dropbox folder, it connects directly to dropbox itself online). In fact it isn't really recommended, where possible, to have your sync target syncing to any local folders - it should just be a single copy on the sync target. So this wouldn't be possible with the existing system at all because it would have to download your data every time the markdown renderer runs (or at least each time per session). At the very least it wouldn't be a very smooth experience.

I guess having an option for an external resource folder that changes the default attachment behaviour wouldn't be impossible, the user would be responsible for syncing it themselves but this is adding quite a lot of extra complexity for a feature I don't think I've seen requested much before (although I'm happy to redact that if people prove me wrong).

Feel free to open this up as a feature request in the features category to see if people do support it. However even if people do support the feature it does not mean it will be accepted if it is decided that it isn't worth adding and maintaining the complexity (I'm very much thinking about the issues with mobile OSs as the permissions for accessing other files is complicated, liable to change and on iOS not even Obsidian can do what you are proposing - it only works via iCloud and their paid sync service).

Can you help move that topic to Futures group ?

I think it would be better served as a new topic, this has already got long and people are unlikely to read it or comment - you can certainly link to this topic from it. It also answers a question (with the answer basically being a long winded "no") in case others search for this question in this category in the future.

Plus it doesn't really have any requirements as such - a good feature request should really have the following if you want people to see and support it:

  • It should not be a duplicate of any existing open request on the forum or github (not saying this is but as a general rule...)
  • Have a good description of what the feature is and how it would benefit the application + users
  • Examples of other applications or services that have this functionality (and if possible how they implement it)
1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.