GNU bug report logs - #35495
27.0.50; Untarring an archive with a keyring.gpg inside

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Date: Mon, 29 Apr 2019 20:04:03 UTC

Severity: normal

Found in version 27.0.50

Full log


Message #47 received at 35495 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35495 <at> debbugs.gnu.org, ueno <at> unixuser.org, federicotedin <at> gmail.com
Subject: Re: bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside
Date: Sat, 11 May 2019 10:10:37 -0400
>> > It isn't clear to me how you distinguish between the file-name
>> > handlers that should and shouldn't be disabled here.
>> Each file-name handler will make that decision on its own.
> Will each handler also write code to implement that decision?

Well, the handler will execute code rather than write it, but yes,
someone will have to change jka and epa to implement this new behavior
of write-region.

> If so, we can stop being bothered by that issue.  But if someone of us
> will have to implement that decision, the question still stands,
> doesn't it?

Hmm... I think you're referring to the question of what this new
"write-region-provides-raw-file-contents" should precisely mean, so that
maintainers of file-name-handlers can decide how to implement it.

Here's one attempt: "the data provided to write-region reflects the actual
bytes that should be placed into the file rather than the data returned
by `insert-file-contents`".

Maybe another way to define it would be: "the data provided to
write-region reflects the data one would like to get from
`insert-file-contents-literally` rather than that returned by
`insert-file-contents`"

And that made me discover that we have another occurrence of the same
problem in `insert-file-contents-literally`:

    (defun insert-file-contents-literally (filename &optional visit beg end replace)
      "Like `insert-file-contents', but only reads in the file literally.
    See `insert-file-contents' for an explanation of the parameters.
    A buffer may be modified in several ways after reading into the buffer,
    due to Emacs features such as format decoding, character code
    conversion, `find-file-hook', automatic uncompression, etc.
    
    This function ensures that none of these modifications will take place."
      (let ((format-alist nil)
            (after-insert-file-functions nil)
            (coding-system-for-read 'no-conversion)
            (coding-system-for-write 'no-conversion)
            (inhibit-file-name-handlers
             ;; FIXME: Yuck!!  We should turn insert-file-contents-literally
             ;; into a file operation instead!
             (append '(jka-compr-handler image-file-handler epa-file-handler)
                     (and (eq inhibit-file-name-operation 'insert-file-contents)
                          inhibit-file-name-handlers)))
            (inhibit-file-name-operation 'insert-file-contents))
        (insert-file-contents filename visit beg end replace)))

So this FIXME suggests maybe we should introduce a new file operation
`write-region-literally`?


        Stefan





This bug report was last modified 3 years and 27 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.