I found this problem while looking into Bug#72641.
* lib-src/etags.c (do_move_file):
* lib-src/update-game-score.c (unlock_file):
* src/androidvfs.c (android_hack_asset_fd_fallback):
* src/filelock.c (current_lock_owner):
Treat unlink as successful if it fails because the file wasn’t there.
This can happen with some NFS implementations, due to its
retrying over the network to get at-least-once semantics.
Although most of Emacs’s calls to unlink were already doing this,
a few instances were not.
(cherry picked from commit
40eecd594ac60f38b6729fd9cf3474a8b9d133b9)
if (fclose (dst_f) == EOF)
pfatal (dst_file);
- if (unlink (src_file) == -1)
+ if (unlink (src_file) < 0 && errno != ENOENT)
pfatal ("unlink error");
return;
char *lockpath = (char *) state;
int saved_errno = errno;
int ret = unlink (lockpath);
- if (0 <= ret)
+ if (! (ret < 0 && errno != ENOENT))
errno = saved_errno;
free (lockpath);
return ret;
if (fd < 0)
return -1;
- if (unlink (filename))
+ if (unlink (filename) && errno != ENOENT)
goto fail;
if (ftruncate (fd, size))
the file system is buggy, e.g., <https://bugs.gnu.org/72641>.
Emacs never creates empty lock files even temporarily, so removing
an empty lock file should be harmless. */
- return emacs_unlink (SSDATA (lfname)) < 0 ? errno : 0;
+ return emacs_unlink (SSDATA (lfname)) < 0 && errno != ENOENT ? errno : 0;
}
\f