verify-visited-file-modtime

verify-visited-file-modtime

[Luc Teirlinck]

Fverify_visited_file_modtime contains:

  if (stat (SDATA (filename), &st) < 0)
    {
      /* If the file doesn't exist now and didn't exist before,
       we say that it isn't modified, provided the error is a tame one.  */
      if (errno == ENOENT || errno == EACCES || errno == ENOTDIR)
      st.st_mtime = -1;
      else
      st.st_mtime = 0;
    }

If the buffer has stored (via the value -1) that the file does not
exist and the file does not exist on disk either, then the buffer's
record agrees with the actual situation on disk.  I do not know which
"untame" errors one had in mind here where
`verify-visited-file-modtime' should return nil in this situation.
Is it good enough if a handler just returns `t' in this situation
without worrying about this?

Sincerely,

Luc.

Re: verify-visited-file-modtime

[Luc Teirlinck]

>From my previous message:

   I do not know which "untame" errors one had in mind here where
   `verify-visited-file-modtime' should return nil in this situation.

>From `(libc)File Name Errors', I would appear that these must be
`ENAMETOOLONG' and `ELOOP'.  Does a handler for
`verify-visited-file-modtime' need to try to detect these from Lisp or
is just returning t in the described situation good enough?

Sincerely,

Luc.

Re: verify-visited-file-modtime

[Richard Stallman]

    If the buffer has stored (via the value -1) that the file does not
    exist and the file does not exist on disk either, then the buffer's
    record agrees with the actual situation on disk.  I do not know which
    "untame" errors one had in mind here where
    `verify-visited-file-modtime' should return nil in this situation.

The idea is that tame errors in this context mean that the name
doesn't exist, where as the other errors (not tame) indicate difficulty
in finding out whether the name exists.