Broken symlinks in new containerless static hosting

Glitch Feedback
1

I have a “static” website project https://trusted-seemly-ceres.glitch.me/ where there are some files that I don’t want under version control, so I put them in .data/, and there are some files in there that I wanted to serve publicly.

Before this change, I would create a symlink from records.txt to .data/records.txt. Now that’s broken, with the symlink and/or the target missing.

I’m just posting this. I haven’t come up with something I want yet.

  • Upload all of .data to the shared static server? Nah, some things in .data/ I want to be private.
  • Resolve symlinks before uploading? That also seems lame.
  • Move these files to another dir and gitignore them? Oh no, more work for us webmasters…
1 Like
2

It seems to me like you should go with option 3.

Your premise,

there are some files that I don’t want under version control, so I put them in .data/ , and there are some files in there that I wanted to serve publicly.

…doesn’t make sense to me. What is the .data folder for, is it hidden things, or public things?

So I’d suggest making a .secret/ for your hidden things and put public things somewhere else.

1 Like
3

To add to that, you don’t need to make another directory. Simply git ignore files and folders you don’t want under source control.

4

I agree with this. If I wanted to make progress right now, I’d definitely go with the option of doing things myself. That’s very much in the spirit of using Glitch.

Good point, that’s a question that I think hasn’t thoroughly been answered in the context of static projects. That question is going to be more valuable now that this huge ‘feature’ for static projects has just landed and will be drawing more attention to it.

Most of the literature on the directory is about (i) it’s excluded from verison control by default and (ii) it’s not copied on fork. (Ah, I forgot to mention that these “record.txt” files don’t need to be copied on fork.) And I’ve made a few posts on this forum about whether or not it lives up to the description of “private” ~mostly with staff agreeing to put protections in place similar to .env.

True fact, and a useful thing to bring up for anyone else reading this. In my case there are many files with a janky script to rotate older ones to different names and stuff, so I think it’ll be neater to shove them all in a directory and have an unchanging .gitignore file.

Thanks for y’all’s concerns about my specific project. I have some ideas of what to do to fix it for myself, although I haven’t committed to putting forth the time to do it yet.

The feedback still stands as feedback though:

  • there’s now a weird difference in how static projects are served between when the project container is running and when the project container is not running
  • the behavior when the project container is not running breaks some normal-ish behavior (I’m trying to maintain that symlinks are normal)
1 Like