☰

当传递的文件路径超过 100 个字符时，crontab 会抛出错误“没有这样的文件或目录”

tag-icon • tag-icon debian cron
当传递的文件路径超过 100 个字符时，crontab 会抛出错误“没有这样的文件或目录” 
$ touch aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBB
$ crontab aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBB
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa: No such file or directory

这种行为看起来很不寻常（注意它如何截断错误消息中的路径）。我正在使用 Debian bullseye 11。

这是一个错误，还是有特定原因导致 crontab 有如此特殊的限制？

我无法在此处的 docker 映像上复制它：https://hub.docker.com/r/willfarrell/crontab

答案1

来自 Cygwin的版本crontab打印一条解释性错误消息：

file=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcd
touch "$file"
crontab "$file"
crontab: usage error: filename too long

echo "$file" | awk '{print length}'
108

该消息解决了您的疑虑，但没有提供任何解释。

不幸的是 Debian 上的版本没有很好地解释：

crontab "$file"
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTU: No such file or directory

echo 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTU' | awk '{print length}'
99

然而，源代码（apt-get source crontab）给出了大量线索cron.h：

#define  MAX_FNAME       100     /* max length of internally generated fn */

然后在crontab.c：

static  char            Filename[MAX_FNAME];
…
(void) strncpy (Filename, argv[optind], (sizeof Filename)-1);
Filename[(sizeof Filename)-1] = '\0';

如果从这些片段中看不出来，文件名的长度有 99 个字符的硬编码限制。除了任意原因之外，我看不出其他原因”那应该足够长了“。正确的方法可能是使用PATH_MAX+1，但作者并没有这样做。 A评论指出该代码最早可能是在 1988 年（或晚在 1994 年）编写的，但很可能是在 POSIX 之前，该常量被形式化。

相关内容