13
$ touch aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBB
$ crontab aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaBBB
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa: No such file or directory

This behavior seems quite unusual (noticing how it also truncates the path in the error message). I'm using Debian bullseye 11.

Is this a bug, or is there a specific reason why crontab has such a peculiar limitation?

I'm not able to replicate it on the docker image here: https://hub.docker.com/r/willfarrell/crontab

0

1 Answer 1

20

The version of crontab from Cygwin prints an explanatory error message:

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

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

The message addresses your concern, albeit without providing an explanation.

Unfortunately the version on Debian doesn't explain well:

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

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

However, the source code (apt-get source crontab) gives a massive clue in cron.h:

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

And then in crontab.c:

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

In case it's not obvious from these snippets, there's a hard-coded 99 character limit on the length of the filename. I can't see a reason for this other than an arbitrary "that should be long enough". The proper approach would probably have been to use PATH_MAX+1, but the author(s) didn't do that. A comment notes that the code could have been written as early as 1988 (or as late as 1994), but quite possibly pre-POSIX where this constant was formalised.

6
  • 2
    Is there is a reason for this limit? Commented Jul 2, 2023 at 17:46
  • 3
    @ChrisStryczynski I didn't write the code, but it looks like it's a completely arbitrary "that should be long enough". The proper approach would probably have been to use PATH_MAX, but the author(s) didn't do that Commented Jul 2, 2023 at 18:19
  • 6
    This has been unchanged by Debian since 1999 when Paul Vixie's cron project was retrieved by Debian: salsa.debian.org/debian/cron/-/blame/master/cron.h#L67 . The value might have been set as early as 1988 (or as late as 1994).
    – A.B
    Commented Jul 2, 2023 at 20:56
  • @A.B so preceding POSIX by some margin. That would make sense, yes, thank you Commented Jul 3, 2023 at 10:22
  • 2
    Good find. I'll send them a PR Commented Jul 3, 2023 at 14:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .