-
-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Made all notes available from nested subdirectories inside /data #70
base: develop
Are you sure you want to change the base?
Conversation
Hi @Gedulis12, thanks for contributing. I appreciate that this change is aimed at keeping the simplicity in the front end. It does however add complexity to the back end so before I dig deeper into the changes, can I ask a couple of initial questions:
|
Hi @dullage , thanks for the feedback. To answer your questions: Could you please elaborate a little on how the subdirectory compatibility will help when using git. Say i already have a note taking system in place where i use markdown files and manage them through git. I might already have directory structure imposed for example:
so if flatnotes would be compatible with subdirectories, a user would be able to simply If, on the other hand compatability for subdirectories is not enabled, the user would have to manually move notes to the root directory which would break the structure in their git repository, which is not ideal if one wants to keep notes somewhat organized. If subdirectories are not exposed in the front end, how do the proposed changes deal with potential duplicate filenames (in different sub-directories)? I have checked and confirmed that when creating new note through web UI, if a note with the same name already exists anywhere under /data, the error is handled gracefully with a pop-up:
If, however i try to create a new .md file with an already existing name manually, web-ui does display both notes, however the content of the note gets duplicated through both of the notes. I believe this can be addressed in a few ways:
I would also argue that complexity is not necessarily added for those users who simply want plug and play solution and don't care about the availability of nested directory structure, as the app does not impose it by default. The bit of complexity gets added only when the user decides that he needs such additional functionality. Also another thing i could suggest is that nested subdirectories could be not compatible by default, but could be enabled in docker-compose through an optional environment variable. That way any additional complexity would be disabled by default. Please let me know what you think and whether you would like me to work on further changes to address the points mentioned above. |
Hi @Gedulis12. If I'm honest, I'm not keen on either of the proposed solutions. They both feel like a hack around the flat nature of the app. That's not to say that I don't want to try and help here though. I can imagine there are others who are in a similar position and would like to use flatnotes and it would be great to have a solution. What I'm thinking is, perhaps there is a way to achieve a flattened shadow copy of a multi-tiered directory structure outside of flatnotes. And then just back flatnotes onto that. As an example, in theory, you could use inotify to create and destroy symlinks in a flat directory to point to files in a hierarchical directory. Or perhaps this is possible with something like mergerfs or UnionFS? |
Hi @dullage , thanks for the feedback. To be honest the proposed workarounds also seem very hacky in nature. They would suggest that complexity which could be handled by the application would be shifted to be handled and maintained by the user himself. I personally would rather not use the application at all if i had dance around with symlinks, shadow copies or other additional layers. On that note, do you think that there is any improvements that could be applied to address your concerns and make you accept the possibility to have notes accessible on nested directories? In any case i'm prepared to maintain a forked version of the application, but i would rather have us reach a consensus :) |
I did have another thought but I haven't yet worked out how it could be achieved or how much work would be involved. What I'm thinking is, maybe flatnotes could support some kind of a bring-your-own-storage model where it would ship with a model to support the current functionality (a single flat directory in the local filesystem) but allow for other models to be used if wanted. Then, rather than maintaining a fork, you'd just need to maintain a plugin. I'd have to separate out the logic a bit but the number of operations the plugin would need to support is minimal (list files, get a file, create a file etc). The benefit of this is that it could potentially allow for other storage options such as S3 or GitHub. |
Wouldn't my previous suggestion work in order to achieve something like this?
The additional functionality could be enabled only if some environment variable is set to true, for example |
Sorry for the late reply. The difference in the plugin approach I mentioned is that the nested directories code would be external to this repo. Although the solution works, it is still a bit of a workaround and as such, not something I'd really like to support as a 1st party feature. |
Just to let you know, I'm also very interrested by the support of existing folder structure . |
@benooye As a workaround i myself am currently using the forked version with support for subdirectories, you can use my version by changing the image in docker-compose.yml configuration to |
Thanks for the information I will try it |
Are there any thoughts about making this an official feature? It's a common practice in documentation apps like Docusaurus for instance. Organizing notes within the file structure using a folder system is really helpful. Thanks for all your efforts on the project! |
I gave your fork a try and it looks decent. However, there's still an issue with the organization on the flatnotes front end. It basically just lists all the .md files in all the folders without displaying the folders themselves or letting you navigate within them. Is there any way to better organize how this works on the front end? Maybe I am doing it wrong? |
Unfortunately not. Really it's a different app entirely ("deepnotes"?). I understand that having just one big folder isn't everyone's cup of tea but it's one of the fundamental design decisions behind the app. |
This was intentional, i was trying to implement the support for nested directory structure on the backend, without compromising the "flat" nature of the app on the frontend. |
I'd also love to have directory support added to flatnotes. It would make this app nearly perfect. Those who don't want a directory structure could just no make directories? |
Love this feature! |
This feature is necessary for me. Hoping it merged soon! |
I think this would be great as well, so I can use flatnotes to search and edit existing notes and wikis. It might make sense to keep the relative path to the notes in the title. That's what you'd get if you just list the files from a flat filesystem like S3. I did come across a few caveats when looking at this solution though..
If we replace the path separator with something else (like → as suggested earlier) then it avoids some of these issues, but also links wouldn't work. Anyway I understand why there's reservations about such a change. I also like the idea of being able to implement a plugin to provide the note storage. |
@danielmcmillan can you expand on the existing issue(s)? That maybe worth a new issue. I was able to create a title in the public demo with the title
Without error but https://demo.flatnotes.io/note/..%252F..%252Ftestdots is not accessible nor https://demo.flatnotes.io/note/../../testdots I've not setup an instance yet to see what the actual behavior on the filesystem is. |
@clach04 I didn't see any major issue, I don't think path traversal is possible. The only issue I found is the ability to create notes that cannot be accessed from the browser like what you have seen. Created #209 |
Hi,
First of all amazing project, the moment i saw this i realized this is a perfect remote access solution for my current note system.
I understand that the goal of the project is for the application to be as simple as possible, however not being able to have deeper directory structure in /data is making this app unusable for users who are also managing their notes through git.
I've made a few simple changes which makes all of the markdown files available from any sub directory inside /data.
Please note that this does not clutter the front-end in any way, the titles are displayed as filename (without .md extension) in the web view, hence the simplicity aspect of the app is kept.
Fingers crossed for this to go through as i would finally have a note taking system that 100% fits my needs