We currently have the option to automatically move inserted attachments into a “… subfolder under the current folder”.
I think it would be nice to turn in into something like “in folder relative to current folder” so you could for example use “…/attachments”.
Example Directory:
Project A
→ Member Profiles
→ Lessons Learned
→ Dont Use SVN.md
→ Whatever
→ Attachments
→ some svn merge Conflict.md
You can infact enter a relative path in the current options. It will create the folder, when inserting some kind of attachment into the note, but the attachment will be saved into the vault root.
If you try again you will get a message in the console telling you that the folder already exists.
Proposed solution
Add support for relative paths in both relative directions.
One variation of this theme would be to have strictly one note per directory and all attachments in the same directory. In this case, a directory would be regarded as a note iff it would contain an _index.md file (as an example). This approach would be my preference because moving and renaming notes and attachments would be trivial also outside of the app.
I’m reaching out regarding the same issue many Obsidian users might be encountering - the need for better future-proofing of our notes as a combination of text and assets.
This critical matter doesn’t get the visibility it deserves due to the way new posts are swiftly deleted or merged and spread across several topics such as textbundle support, attachement folder name, and foldernotes.
Context
Obsidian’s robustness shines, but when it comes to attachment management, things get chaotic and that hinders the efficiency of my vault.
Use case or problem
When capturing web pages, either I get only markdown text without images, or I add images to the vault where they remain loosely connected to my note and stored in a messy asset folder.
Scanned paper invoices along with notes necessitate manual handling of images when notes are relocated.
In cases like a note containing personal photos, images remain detached, making potential migrations cumbersome.
Notes in Obsidian are often a blend of text and images, losing significant context without their assets. The markdown-only approach future-proofs the text but leaves the whole note (text + assets) vulnerable.
Current workaround
FolderNote - I place assets within folders, but this involves a lot of manual work. Also, it results in a mixed bag of markdown notes and folders, making things cluttered and hard to manage. In the screenshot below, notes with attachements are in red, those without are in blue.
Bear App - I use a Python script to scan my vault, detect attachment errors, create a TextBundle backup, and import it to Bear for integrity checks. I am also waiting for Bear 2, which may better serve my needs.
Proposed solution
My focus in Obsidian is handling notes, not their attachments. Attachments should follow a note seamlessly when moved or exported.
By merely dragging and dropping or scanning an asset, it should integrate into the note automatically. This transforms the Obsidian vault into a hub of standalone notes, eliminating the separate asset directory.
Imagine the Obsidian interface retaining its familiarity, yet with a streamlined process for asset embedding beneath, enhancing its organization and adaptability.
I came here with the same request. A single attachments folder per vault is definitely better than them all being in root. But my ideal would be to be able to specify an attachment sub-folder per high-level folder. A new image would then save to the “nearest” attachment folder on its path.
Came here to post a similar request so shall add mine as a comment: Can we also have a default save location for assets in the settings like we do with the daily notes and new notes.
I like how typora keeps assets related to a note in (linked by name) a separate folder.
In note system where you move notes between folders, this helps out a lot in migration.
For e.g. - I put daily notes in Inbox folder then at EOD sort them in respective folders. Although obsidian doesn’t mind it, moving attachments takes care of OCD tick.
In rare case if I delete a note, it will also let me know if any there any lingering attachments left.
I use Greenshot a lot when writing articles and copy images to the clipboard before pasting them into the documents I am working on.
Current behavior
A generic image name is automatically assigned to the image (With no easy way of renaming the file name afterwards.)
Only one asset folder location can be specified
I typically have many images in my documents and putting them all in the one folder gets really messy really quickly. I basically need one image folder per document.
Improvement suggestions
When pasting an image, show the image in a pop-up window and allow the user to name the image and choose the folder it should be stored in.
Allow each markdown document to specify the folder path the images should be saved into, in the YAML frontmatter. (Should be able to work with relative paths to the document location)
A combination of the 2 previous points. (but would be very happy if only point 2 was implemented)
Aim
A really seamless way of quickly inserting images into documents and automatically saving them in the correct folder.
Allow the user to name the file as it is pasted into the document or being able to easily rename the file after it is pasted.
Thanks for bringing this up. I agree that this would be very useful. Even having a date-prefix to the pasted image would be more useful than “Pasted image”.
Hi all, I would find it very useful to have an attachment folder per topic in a particular vault. For example Vault 1 has four separate topic folders. I would like to see an attachment folder for each of the four separate topics – they are different historical eras.
Trust this makes sense and meets wil approval, but if it is not possible, this is still an amazing software package. Thank you very much.
Adrian
Agree, it’s unsolved problem. Not sure if there’s one-size-fits-all approach.
Providing more configurable options would be a positive development though. Being able to define default folders depending on where in the folder structure one is, would be a welcome improvement.
