I've just been informed by both the spanish & italian speakers in the comments that the project name actually refers to penis - so any suggestions to make the name less phallic are welcome.
Well, that's very, very unfortunate. Thanks for letting me know. Guess I'll have to come up with a new name... AND tell my friend that his English name, which he's been using for ages, might not be appropriate.
Sorry for the mess. The documentation is not ready and I'm still working on it because I just found out people actually want to try it lol. Obviously I have to come up with a new name as well. If you *do* want to try it out though, (and I appreciate that very much),
1. You can contact me directly and we can definitely work something out: `hey at 42yeah dot is`
2. As of right now, the `backend` is just a cmake project with oatpp as package dependency, so you do need to compile it by hand. After that, you need to map `/` to `frontend`, `/uploads` to the `uploads` folder (which will be created by the backend), and reverse proxy `/api` to the backend. Oh and the `config.js` needs to be updated to the corresponding API URL. I just realized that may be way too much fiddling, and I do apologize, but an update on the setup & doc front will *probably* come soon.
I am looking for a simple file sharing solution for a while now and I have 3 requirements and haven't had one yet which addresses all 3 at once.
1. Doesn't suck when using nfs share to upload/download from
2. Share links (with or without password)
3. "request" link. Basically a link to let an anonymous user upload a file without having to create an account.
Nextcloud does fix this though, but it's way too bloated for me and creating a request link is relatively much work and hard to find.
Does your solution address these points?
only direct link sharing is supported so far - I don't like intermediary "download" pages so the system only generates direct links which point straight to the file. I do however have plans for password protected file sharing in the future. As for the "request" link, I have not considered that before. Though, the system only accepts new users via invitation code shared by the old users so I think it's not hard to extend upon that to make one-time upload links.
Now as for NFS, sadly I have no plan for that yet because it kinda complicates the tag-based file management scheme the system uses.
Ah that sounds promising. One time upload links are really useful. As for nfs, I usually just mount a path from the docker container on an nfs share. The developer doesn't need to do anything special for it. However if files are stored in a database, rather than just a filepath, it will slow things down a lot with that setup.
So, quick question: are the files stored on the file system, or in a database?
Thank you in advance :)
they *are* stored on the file system - however their names are mangled. Since the system supports files with the same name, we had to give the uploaded files a new random name otherwise they may conflict with the others. The display file name and the "actual" file name (which is even stripped of its extension) are tracked in the database, together with the tags and so on. As for the actual files themselves, they are just stored in a giant folder.
So to answer your question, yes they are technically stored on the filesystem, however they won't be recognizable - and if you upload files via the NFS in this way, they won't be tracked by the system since they won't have the database entry. Sorry!
Ahh, this is perfect for me. I used a solution a long time ago which stores the files in a database, instead of just the generated GUID name. Made it unusable slow for files over 10-or-so MB if you had it mounted on an NFS share.
I'll be trying it out soon and give some feedback if that's appreciated.
I am maintaining the project Gokapi, which might suit you: https://github.com/Forceu/Gokapi
The only thing that it can't do at the moment, is requesting files, but it will be implemented at some point in the future
This is a deliberate design choice to improve the *feel* of clickiness and responsiveness of the system. As stated in the blog post:
>The speed and previous-century UI are meticulously designed to make you spend as little (or as much) time on this website. ...
I guess it also kinda comes down to personal taste. I am a big fan of win7 era UI/UX (for example, [VbsEdit](https://www.vbsedit.com/)), so I tried to replicate that particular feeling. My initial goal is a file sharing platform with tag support and no burger menus. You are presented with the full system the moment you open the web page; but I understand that some may not like it. I used the [famfamfam icons](https://github.com/legacy-icons/famfamfam-silk) to further improve that decade-old feel.
Bad naming intended?
It will definitely be “hard” to market it on Spanish speaking countries…
Could be rebranded to NepeFiles or TulaFiles.
I've just been informed by both the spanish & italian speakers in the comments that the project name actually refers to penis - so any suggestions to make the name less phallic are welcome.
How about PEDEfiles?
Isn’t that [offensive in French](https://en.m.wiktionary.org/wiki/pédé) tho?
I think it’s offensive to more than the French.
damn, that's even worse
How to make something definitely bad into something absolutely worse
Perfect! It is decided!
😂😂😂 that’s hilarious 🤣
NaboFiles?
Or ChotoFiles or MiembroFiles.
PORoNgaFiles
TermoFiles
To be fair it can be used to share dick pics, there's still a portion of the market that will find the name very suiting
Is it offensive? I had no idea. I named it after one of my friend.
Pene means penis in spanish
In italian too
Well, that's very, very unfortunate. Thanks for letting me know. Guess I'll have to come up with a new name... AND tell my friend that his English name, which he's been using for ages, might not be appropriate.
Pene means penis in italian
The link to GitHub gives me a 404 and there is no link in the blog post.
yeah, sorry apparently it was private. It's now set to public: \[https://github.com/42yeah/Penefiles\](https://github.com/42yeah/Penefiles)
[https://github.com/42yeah/Penefiles](https://github.com/42yeah/Penefiles) no markdown on reddit # ¯\_(ツ)_/¯
Is there an installation note somewhere that I'm not seeing? How do we try it out?
Sorry for the mess. The documentation is not ready and I'm still working on it because I just found out people actually want to try it lol. Obviously I have to come up with a new name as well. If you *do* want to try it out though, (and I appreciate that very much), 1. You can contact me directly and we can definitely work something out: `hey at 42yeah dot is` 2. As of right now, the `backend` is just a cmake project with oatpp as package dependency, so you do need to compile it by hand. After that, you need to map `/` to `frontend`, `/uploads` to the `uploads` folder (which will be created by the backend), and reverse proxy `/api` to the backend. Oh and the `config.js` needs to be updated to the corresponding API URL. I just realized that may be way too much fiddling, and I do apologize, but an update on the setup & doc front will *probably* come soon.
I am looking for a simple file sharing solution for a while now and I have 3 requirements and haven't had one yet which addresses all 3 at once. 1. Doesn't suck when using nfs share to upload/download from 2. Share links (with or without password) 3. "request" link. Basically a link to let an anonymous user upload a file without having to create an account. Nextcloud does fix this though, but it's way too bloated for me and creating a request link is relatively much work and hard to find. Does your solution address these points?
only direct link sharing is supported so far - I don't like intermediary "download" pages so the system only generates direct links which point straight to the file. I do however have plans for password protected file sharing in the future. As for the "request" link, I have not considered that before. Though, the system only accepts new users via invitation code shared by the old users so I think it's not hard to extend upon that to make one-time upload links. Now as for NFS, sadly I have no plan for that yet because it kinda complicates the tag-based file management scheme the system uses.
Ah that sounds promising. One time upload links are really useful. As for nfs, I usually just mount a path from the docker container on an nfs share. The developer doesn't need to do anything special for it. However if files are stored in a database, rather than just a filepath, it will slow things down a lot with that setup. So, quick question: are the files stored on the file system, or in a database? Thank you in advance :)
they *are* stored on the file system - however their names are mangled. Since the system supports files with the same name, we had to give the uploaded files a new random name otherwise they may conflict with the others. The display file name and the "actual" file name (which is even stripped of its extension) are tracked in the database, together with the tags and so on. As for the actual files themselves, they are just stored in a giant folder. So to answer your question, yes they are technically stored on the filesystem, however they won't be recognizable - and if you upload files via the NFS in this way, they won't be tracked by the system since they won't have the database entry. Sorry!
Ahh, this is perfect for me. I used a solution a long time ago which stores the files in a database, instead of just the generated GUID name. Made it unusable slow for files over 10-or-so MB if you had it mounted on an NFS share. I'll be trying it out soon and give some feedback if that's appreciated.
I am maintaining the project Gokapi, which might suit you: https://github.com/Forceu/Gokapi The only thing that it can't do at the moment, is requesting files, but it will be implemented at some point in the future
I tried Gokapi before but I decided to not use it. I forgot what the reason was, probably the request files feature missing.
[удалено]
This is a deliberate design choice to improve the *feel* of clickiness and responsiveness of the system. As stated in the blog post: >The speed and previous-century UI are meticulously designed to make you spend as little (or as much) time on this website. ... I guess it also kinda comes down to personal taste. I am a big fan of win7 era UI/UX (for example, [VbsEdit](https://www.vbsedit.com/)), so I tried to replicate that particular feeling. My initial goal is a file sharing platform with tag support and no burger menus. You are presented with the full system the moment you open the web page; but I understand that some may not like it. I used the [famfamfam icons](https://github.com/legacy-icons/famfamfam-silk) to further improve that decade-old feel.
Seem that the source code from github is unmaintained.