Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
i3: Could not fread: Is a directory #3531
I'm submitting a…
[x] Bug [ ] Feature Request [ ] Documentation Request [ ] Other (Please describe in detail)
When starting i3 it prints the error in the subject line and terminates. This started with arch linux's recent upgrade of i3. The offending version of i3 is 4.16
Should start normally
Just start i3
I'll get back to this later. It's inconvenient using a web interface with no WM.
I tried this debug function once before but with no luck
- Linux Distribution & Version: Arch, current. - Are you using a compositor (e.g., xcompmgr or compton): No
What location is your config in and can you make sure you don't have one in the other default locations? So, particularly, check ~/.config/i3/config and ~/.i3/config.
With 4.16 the precedence has been changed to prefer the XDG path, and I suspect that this change is the reason you're seeing the error (but in itself doesn't explain the error).
I solved it. My config traditionally lives at .i3/config, and all was fine until 4.16. After hitting this bug, I deleted my .i3/config, you started OK, prompted and created a default config at .config/i3/config which then ran in the default way. When I deleted that and moved my own .i3/config to .config/i3/config, then everything works as I configured it. I've had this effect on two different machines.
This is a bug. If you're not looking in .i3/config anymore then I'd have expected you to prompt to make a new config, but actually, the presence of .i3/config trips you up. The exact same config file in .config/i3/config works fine, so my config contents are not at fault.
One small detail: all of the above-mentioned files (except the one you generated) are actually symlinks to my own config/i3 which is part of my github repo where I keep all different configs. Once I got a strange "too many levels of symbolic links" message although everything had worked before the upgrade to 4.16. That was on the other machine where I fixed it by making the symlink from an absolute path.
BTW: The only reason it's a symlink is that you still won't do the include directive.
We do still look there, the XDG path just has precedence, as required by the spec.
It sounds like i3 found a file (somewhere) and then failed reading it, then bailed.
That makes me think the precedence isn't the issue, since it would seem like it found the non-XDG file. Off the top of my head I don't know if there were other changes regarding loading the config. We'll have to see if we can reproduce the issue. Symlinks should definitely work, if set up correctly.