"Invalid time specification" trying to generate autoloads when el-get-dir or el-get-autoload-file follows a symlink

[seanlynch]

My ~/.emacs.d is a symlink to ~/homedir/emacs.d because I keep all the git-managed stuff in my home directory under a single directory and then symlink to it. As a result, .loaddefs.el's buffer name fails to match "el-get-autoload-file" in el-get-update-autoloads, causing autoloads.el to think it's a secondary autoload file and put MD5 checksums instead of timestamps. This results in an "Invalid time specification" error trying to regenerate the autoloads as it tries to compare the checksum to a timestamp. I am working around this by customizing el-get-dir to point at the real name of the directory, but this is ugly.

It's not clear to me why this is happening, since el-get-update-autoloads is setting el-get-visit-truename to nil, and that's what I have it set to anyway. All I can think is that the fact that it's also under a git-managed directory might be causing vc-mode to modify the name as well?

[npostavs]

Maybe vc-follow-symlinks could affect this?

[seanlynch]

That does seem like a possible culprit, but I have it set to "ask". I wouldn't think it would modify the name when the file was being visited non-interactively.

I converted one system to have my home directory be a Git workdir to avoid needing symlinks, and that made the problem go away. I have another that I haven't converted, so I'll try it with that.

[priyadarshan]

I am using stow (from WSL) to manage my dotfiles and I experience same problem on Windows.

When symlinking .emacs.d (real symlink of course), I get

error in process sentinel: Invalid time specification

This happens with any of

(setq vc-follow-symlinks 'ask)
(setq vc-follow-symlinks t)
(setq vc-follow-symlinks nil)

but not for all packages. The error above happens, for example, with helm.

[priyadarshan]

I apologise to butt in again. Issue on Windows disappears using junction links instead of symbolic links.