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


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 35495 <at> debbugs.gnu.org, Daiki Ueno <ueno <at> unixuser.org>
Subject: bug#35495: 27.0.50; Untarring an archive with a keyring.gpg inside
Date: Sat, 11 May 2019 08:54:47 -0400
>> Instead, you should state the property you want, and then let each
>> file-name-handler decide how to handle that property.  E.g.:
>>
>>     (let ((write-region-provides-raw-file-contents t))
>>       (write-region ...))
>>
>> Of course, the problem here is that by using dynamic scoping, this var
>> will affect all write-regions that will take place during this call,
>> which might lead to more problems.
>
> I see, I hadn't realized that tar-mode still used dynamic scoping (I
> imagine converting it to lexical is a lot of work).

All files use dynamically scoped variables.  `lexical-binding` only
determines the scoping to use for those vars that aren't declared as
dynamically scoped.  The fact that tar-mode.el hasn't (yet) been
converted to use lexical-binding has no effect on the above example
(because I presume there that write-region-provides-raw-file-contents
would be a variable declared somewhere in files.el as being dynamically
scoped, like file-name-handler-alist).

>> Maybe it would be better to have it as an argument to `write-region`, or
>> to introduce a new function?
>>
>> Or maybe, not use `write-region` but `copy-file` instead (which already
>> provides the expected semantics (i.e. it doesn't (un)compress or
>> (en/de)crypt, IIUC).
>
> It looks like `copy-file` only deals with files and not buffers, so we
> would need to find a way to use it from tar-mode.

I know.  Maybe we can extend it to allow the source to be a buffer?

> Looking at the source in fileio.c, it also seems like it uses
> `find-file-name-handler` for `FILE` or `NEWNAME`, so it's possible it
> won't be useful for us.

Not sure why you think that could make it not useful.

> If we added a new argument to `write-region` like you mentioned, say
> `RAW`, could we then use symbol properties to decide whether the found
> file name handler can be used or not?

No, no: we do want the file-name-handler to be called.
We just want it to receive enough info to determine how it will do its
job (e.g. whether it needs to compress/encrypt the data or not).


        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.