GNU bug report logs -
#60146
file-exists-in-trash-p needs better name or semantics
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Sat, 17 Dec 2022 05:18:01 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
Message #8 received at 60146 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 16 Dec 2022 21:17:13 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> The recently-added function (file-exists-in-trash-p FILE) is poorly
> named since it's not really related to trash - it's simply checking for
> the existence of a directory entry named FILE.
>
> How about extending file-exists-p instead? (file-exists-p FILE t) would
> be like (file-exists-p FILE) except it would not follow symlinks. This
> extension can be implemented via a single system call on POSIX systems,
> and this would be more efficient and would avoid a race in the current
> implementation of file-exists-in-trash-p. (Though of course pretty much
> any use of this new function makes one vulnerable to races....)
>
> If extending file-exists-p is too much, at least please rename
> file-exists-in-trash-p to something like files--exists-nofollow-p, to
> indicate that it's private to files.el and to say better what it means.
I don't really mind renaming that function, but the reason I called it
like I did was that apparently no one needed such a functionality in
Emacs until now, except in this obscure use case of moving to trash.
That seems to tell me that extending file-exists-p would be a solution
waiting for the problem, something that we don't like doing.
In any case, if we do decide to extend file-exists-p, it would need to
be done on master, as that is not a trivial change, which has to be
done in C.
Lars, Stefan, WDYT?
This bug report was last modified 2 years and 158 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.