Thursday, 20 March 2025

Stuff learned on this day!

So today/the time between the previous post and now, I have thrown away the idea of doing a login system. I came to this when, after a while trying to figure out how to do it in Blazor, realized that only I would be logging in and no one else. Therefor, it made no sense to have a login system that was only for me. So I went back to the drawing board and realized, I can easily upload the files through SMB to my NAS. I simply created a new Dataset and bind the Docker container that my site uses, to that Dataset. So my Docker container sees wwwroot/external/blogs in its container. There is an interesting effect though. I have no idea why but, for some reason when my site goes to read the file names, it crashes when that binding is set to read-only.

Figuring out what is going on.

I still have no idea what is going on, maybe one day I will though. In any sense, I started by doing the forbidden, the horrible, the thing all IT Security personal knows is bad, I did the unholy, 777 permissions. That didn't fix the issue though, relieved knowing that permissions wasn't the issue, I decided to set the binding to rw, and now my site doesn't crash when reading the file names. I still don't have the answer, and I would love to make that bind ro to help prevent any case of abuse.

My current theory is that .NET is doing something under the hood, where it is requesting write permissions to the folder. It shouldn't, but this is Microsoft of course, it is the same people who can't make a stable OS from my experience. The same people who released a bug that deleted files for people with certain CPUs. I digress though, for as if this is correct, it makes no sense why .NET would want to have write access to a folder that is it reading from. ES MACHT KEINEN SINN! My other theory is that, somewhere in my code, or in the .NET APIs, it opens a file then closes the fd when reading file names. If this is the case, I would consider it a bug.

Update to Site

By the way, as stated above, I did update the site to be a lot more responsive. Instead of having a database that stores all the blog file locations, names, and date. The site will actually use the file name as the date, and it knows that all blogs are located in /wwwroot/external/blogs. This means that any time, say, the site is reloaded or the page updates in any way, the server will look through that directory for any new blog files. It will also check for deleted ones as well. I think, however, in the future I might update it to cache all the blog locations and date. With how it is currently is:

• Pro
  • Updates in real time.
  • No bloated middleman.
  • No database to manage.
• Con
  • The server has to spend time re-looking at files that probably won't change for months.
    • This wastes cycles on a useless task.
    • Slows down loading time the more blogs there are.
  • I am relying on the file system response.

What I have been thinking is keeping a memory map or creating a cache file. The benefits of a cache file is that all of that info is stored in 1 place, and one idea is re-introducing the SQLite DB for that job, as the cache file would be just storing the date and the path of the file. Another option is using a simple dictionary like Dictionary<DateOnly,string> to store both the date and the path. And another option would creating a new class to store the info. The thing I can think of off the top of my head is:

public sealed class Blog {
    public DateOnly Date {
        get;
        private set;
    }
    
    public string Path {
        get;
        private set;
    }
    
    public Blog(DateOnly date, string path){
        Date = date;
        Path = path;
    }
}

Of course this is a rough draft of the class, but that might be interesting to do. The downside to this is that it may consume a lot of memory when it comes to having a lot of blogs. One quick way to remedy this would be to only store the Date, as that is only 3 int's. So it would look something like:

public sealed class Blog {
    public DateOnly Date {
        get;
        private set;
    }
    
    public string Path => $"wwwroot/external/blogs/{Date.Day}-{Date.Month}-{Date.Year}.md";
    
    public Blog(DateOnly date){
        Date = date;
    }
}

This would enable the class to be smaller and allow for more in memory, but then the issue comes from it just sitting in memory doing nothing. Would it be fast? Yes, but at the cost of hogging memory. I think the best route would be to use the SQLite DB as a cache file. This is what databases are designed for, and namely SQLite.

^{If you couldn't tell, I hate unoptimized code. Stop throwing hardware at a software issue companies!}