ArkHost/HelixNotes
14
150
Fork
You've already forked HelixNotes
13

Move the attachment folder at the root of the vault #13

Closed
opened 2026年03月08日 11:08:24 +01:00 by slimhk45 · 6 comments

Hey @ArkHost,
I’ve been thinking about a potential middle ground to make HelixNotes a bit more interoperable with Obsidian with minimal effort.

Right now, storing the attachment folder as a hidden directory means Obsidian can’t read or access those files natively. Since many users like to share vaults across different markdown apps, this creates a bit of friction as we discussed on Discord.

Instead of using a hidden folder, what do you think about storing attachments at the root of the vault in a visible folder prefixed with a symbol (like a + folder or __attachments folder)?

This keeps the folder firmly out of the way of the user's main notes, but ensures Obsidian can still index and display the media.
Here is an example of what that structure would look like:

📁 Vault Root
├── 📁 .helixnotes <-- HelixNotes config files here
├── 📁 __attachments <-- HelixNotes manages media files here
│ ├── image.png
│ └── book.pdf
├── 📁 Daily
└── 📁 Library

This approach maintains a clean file structure while keeping both apps happy. Let me know what you think of this approach!

Hey @ArkHost, I’ve been thinking about a potential middle ground to make HelixNotes a bit more interoperable with Obsidian with minimal effort. Right now, storing the attachment folder as a hidden directory means Obsidian can’t read or access those files natively. Since many users like to share vaults across different markdown apps, this creates a bit of friction as we discussed on Discord. Instead of using a hidden folder, what do you think about storing attachments at the root of the vault in a visible folder prefixed with a symbol (like a `+` folder or `__attachments` folder)? This keeps the folder firmly out of the way of the user's main notes, but ensures Obsidian can still index and display the media. Here is an example of what that structure would look like: ``` 📁 Vault Root ├── 📁 .helixnotes <-- HelixNotes config files here ├── 📁 __attachments <-- HelixNotes manages media files here │ ├── image.png │ └── book.pdf ├── 📁 Daily └── 📁 Library ``` This approach maintains a clean file structure while keeping both apps happy. Let me know what you think of this approach!

I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder.

I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things.

I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder. I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things.

@grazing-saucy wrote in #13 (comment):

I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder.

I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things.

You mix things here. Linux uses dot files for config files, not for anything else. We are talking about attachments here. The config folder would stay with a dot prefix like Obsidian does.

Hiding attachments is tricky, because most users tend to think of config files as something disposable. If a HelixNote user deletes the dot folder, they would delete all their attachments as well. Bad design. It is not just about interoperability with Obsidian.

@grazing-saucy wrote in https://codeberg.org/ArkHost/HelixNotes/issues/13#issuecomment-11364550: > I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder. > > I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things. You mix things here. Linux uses dot files for config files, not for anything else. We are talking about attachments here. The config folder would stay with a dot prefix like Obsidian does. Hiding attachments is tricky, because most users tend to think of config files as something disposable. If a HelixNote user deletes the dot folder, they would delete all their attachments as well. Bad design. It is not just about interoperability with Obsidian.

Thanks for the suggestion and the discussion.

To clarify one point: dot-prefixed folders on Linux just mean "hidden from default directory listings." There's no convention that limits them to config files - .git/, .cache/, .local/, .Trash-1000/ are all dot-prefixed and none are config. So the current hidden folder approach for media aren't breaking any Linux conventions.

That said, I can see the argument for making the attachments folder visible. It's something I'll look into, but it's not a priority right now - the current setup works correctly and there are more important things on the roadmap.

Thanks for the suggestion and the discussion. To clarify one point: dot-prefixed folders on Linux just mean "hidden from default directory listings." There's no convention that limits them to config files - .git/, .cache/, .local/, .Trash-1000/ are all dot-prefixed and none are config. So the current hidden folder approach for media aren't breaking any Linux conventions. That said, I can see the argument for making the attachments folder visible. It's something I'll look into, but it's not a priority right now - the current setup works correctly and there are more important things on the roadmap.

@slimhk45 wrote in #13 (comment):

@grazing-saucy wrote in #13 (comentário):

I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder.
I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things.

You mix things here. Linux uses dot files for config files, not for anything else. We are talking about attachments here. The config folder would stay with a dot prefix like Obsidian does.

Hiding attachments is tricky, because most users tend to think of config files as something disposable. If a HelixNote user deletes the dot folder, they would delete all their attachments as well. Bad design. It is not just about interoperability with Obsidian.

I can understand the reasoning behind wanting interoperability, mas calling this bad design is absolutely a lack of understanding on your part. Dot files just mean they are hidden, in absolutely no way can a dot folder be interpreted as "disposable" just because it is hidden

@slimhk45 wrote in https://codeberg.org/ArkHost/HelixNotes/issues/13#issuecomment-11366077: > @grazing-saucy wrote in #13 (comentário): > > > I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder. > > I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things. > > You mix things here. Linux uses dot files for config files, not for anything else. We are talking about attachments here. The config folder would stay with a dot prefix like Obsidian does. > > Hiding attachments is tricky, because most users tend to think of config files as something disposable. If a HelixNote user deletes the dot folder, they would delete all their attachments as well. Bad design. It is not just about interoperability with Obsidian. I can understand the reasoning behind wanting interoperability, mas calling this bad design is absolutely a lack of understanding on your part. Dot files just mean they are hidden, in absolutely no way can a dot folder be interpreted as "disposable" just because it is hidden

@grazing-saucy wrote in #13 (comment):

@slimhk45 wrote in #13 (comment):

@grazing-saucy wrote in #13 (comentário):

I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder.
I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things.

You mix things here. Linux uses dot files for config files, not for anything else. We are talking about attachments here. The config folder would stay with a dot prefix like Obsidian does.
Hiding attachments is tricky, because most users tend to think of config files as something disposable. If a HelixNote user deletes the dot folder, they would delete all their attachments as well. Bad design. It is not just about interoperability with Obsidian.

I can understand the reasoning behind wanting interoperability, mas calling this bad design is absolutely a lack of understanding on your part. Dot files just mean they are hidden, in absolutely no way can a dot folder be interpreted as "disposable" just because it is hidden

The dot notation is actually an exclusion pattern for file processing algorithms, and it is also used for software-managed files, i.e. files the user should not manage via the system file manager but via the software UI. 99% of the time it is about config files or disposable files. The system trash and the config folder of Obsidian are two examples mentioned in the discussion.

We agree on the rest.

@grazing-saucy wrote in https://codeberg.org/ArkHost/HelixNotes/issues/13#issuecomment-11383891: > @slimhk45 wrote in #13 (comment): > > > @grazing-saucy wrote in #13 (comentário): > > > I am all for interoperability, and while I don't use Obsidian, using a dot prefixed folder is highly interoperable already - the whole linux world knows to treat this as a hidden folder. > > > I would prefer if this change came as an option for those interested, without breaking the "linux way" of doing things. > > > > > > You mix things here. Linux uses dot files for config files, not for anything else. We are talking about attachments here. The config folder would stay with a dot prefix like Obsidian does. > > Hiding attachments is tricky, because most users tend to think of config files as something disposable. If a HelixNote user deletes the dot folder, they would delete all their attachments as well. Bad design. It is not just about interoperability with Obsidian. > > I can understand the reasoning behind wanting interoperability, mas calling this bad design is absolutely a lack of understanding on your part. Dot files just mean they are hidden, in absolutely no way can a dot folder be interpreted as "disposable" just because it is hidden The dot notation is actually an exclusion pattern for file processing algorithms, and it is also used for software-managed files, i.e. files the user should not manage via the system file manager but via the software UI. 99% of the time it is about config files or disposable files. The system trash and the config folder of Obsidian are two examples mentioned in the discussion. We agree on the rest.

Closing this issue for now.

Closing this issue for now.
Sign in to join this conversation.
No Branch/Tag specified
main
fix/vault-indication
v1.3.3
v1.3.2
v1.3.1
v1.3.0
v1.2.9
v1.2.8
v1.2.7
v1.2.6
v1.2.5
v1.2.4
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.1.9
v1.1.8
v1.1.7
v1.1.6
v1.1.5
v1.1.4
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.9
v1.0.8
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3
v1.0.2
v1.0.1
v1.0.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ArkHost/HelixNotes#13
Reference in a new issue
ArkHost/HelixNotes
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?