GNU bug report logs -
#42431
28.0.50; browse-url-of-dired-file confusing messaging
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Sun, 19 Jul 2020 19:35:02 UTC
Severity: normal
Found in versions 28.0.91, 28.0.50, 28.0.60
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: michael.albinus <at> gmx.de, 42431 <at> debbugs.gnu.org
>> Date: Sat, 08 Aug 2020 12:05:04 +0200
>>
>> >> (condition-case ()
>> >> (let ((inhibit-read-only t))
>> >> (insert-file-contents-literally filename t))
>> >> (file-error
>> >> (when (and (file-exists-p filename)
>> >> (not (file-readable-p filename)))
>> >> (kill-buffer buf)
>> >> (signal 'file-error (list "File is not readable"
>> >> filename)))
>> >
>> > Is this because file-readable-p returns nil for file:// URLs?
>>
>> That's the direct cause of the message, but the underlying reason is
>> that insert-file-contents-literally signalled a file-error here (after
>> inserting the contents). I haven't yet chased down why.
My analysis here was kinda wrong -- the code above isn't what gives the
warning, because all those functions up there do the right thing, since
file-name-handler-alist is set:
(let ((file-name-handler-alist
(cons (cons url-handler-regexp 'url-file-handler)
file-name-handler-alist)))
(list (file-exists-p "file:///tmp/a.txt")
(file-readable-p "file:///tmp/a.txt")))
=> (t t)
The problem is that insert-file-contents signals a file-error, and the
error string is "Success". This makes things confused, because it knows
that it has an error, but when it tests for all things that could go
wrong, it doesn't find anything, and ends up here:
(defun after-find-file (&optional error warn noauto
_after-find-file-from-revert-buffer
nomodes)
[...]
((and error (file-attributes buffer-file-name))
(setq buffer-read-only t)
(if (and (file-symlink-p buffer-file-name)
(not (file-exists-p
(file-chase-links buffer-file-name))))
"Symbolic link that points to nonexistent file"
"File exists, but cannot be read"))
Which is where the message itself comes from.
> So one solution would be to convert file:// URLs into local file names
> in the above snippet, before calling insert-file-contents-literally.
It would be, but I think this points to an error in insert-file-contents
itself. I'll poke around some more...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
This bug report was last modified 2 years and 218 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.