GNU bug report logs -
#69517
[PATCH] Make gnus cache work with group names having '/'
Previous Next
Reported by: James Thomas <jimjoe <at> gmx.net>
Date: Sun, 3 Mar 2024 01:56:01 UTC
Severity: normal
Tags: patch
Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#69517: [PATCH] Make gnus cache work with group names having '/'
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 69517 <at> debbugs.gnu.org.
--
69517: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69517
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
On 03/29/24 05:39 AM, James Thomas wrote:
> Eli Zaretskii wrote:
>
>> Ping! Is there anything else left to be done here, or should we close
>> this?
>>
>>> From: Daniel Semyonov <daniel <at> dsemy.com>
>>> Cc: 69517 <at> debbugs.gnu.org, Eric Abrahamsen <eric <at> ericabrahamsen.net>, Eli
>>> Zaretskii <eliz <at> gnu.org>
>>> Date: Fri, 15 Mar 2024 19:33:42 +0200
>>>
>>> >>>>> James Thomas writes:
>>>
>>> > Eric Abrahamsen wrote:
>>> >> The real problem (well, one of the real problems) is that we should just
>>> >> have two central routines for reading and writing active files, so that
>>> >> there are only two places to keep in sync. Instead we have those two
>>> >> places, and then a smattering of other functions in other places that do
>>> >> something similar, and also have to be kept in sync, and I haven't done
>>> >> that. At the very least I'll need to apply your patch from 65467.
>>> >>
>>> >> The other real problem is that gnus-cache is confused about whether it
>>> >> wants to be a select method, or a modified version of article saving.
>>> >> The presence of `gnus-use-long-file-name' indicates the latter, but the
>>> >> manual's instructions about the nnml select method indicates the former.
>>> >>
>>> >> I think it should be a select method, which means that the group
>>> >> directory should be created in "News/cache" the same way it is created
>>> >> at the top level: with the "/" replaced by "_", and everything else
>>> >> using the proper "left/right" group name. Perhaps "long file names" can
>>> >> still play a role, but if so that should be via
>>> >> `nnmail-use-long-file-names', and gnus-cache in general should behave
>>> >> like a nnmail backend.
>>>
>>> > Well, I have sort of, an approach based on my earlier patch: [patch]
>>>
>>> > James Thomas wrote:
>>>
>>> >> + (if (not nnmail-use-long-file-names)
>>> >> + (nnheader-replace-chars-in-string group ?. ?/)
>>> >> + group))
>>>
>>> > Since directory names cannot have '/' they used to be replaced by '_' in
>>> > group names before conversion. But this makes it impossible, when
>>> > generating (non-existent) active files to know whether a '_' in the
>>> > directory name was _ or / originally.
>>>
>>> > The above patch tries a possible solution inspired from [1] but would
>>> > break existing users of the cache or agent (xref-find-references
>>> > "nnmail-group-pathname") who have groups with % or / in their names.
>>>
>>> > Seems to work in my limited testing. WDYT?
>>>
>>> I tested it and it seems to work, but I'm pretty sure it will also break
>>> existing groups with % or / in their names in several backends.
>>> For example, the `nnmh' and `nndiary' backends use this function to
>>> locate groups on disk, which will fail for those groups (unless users
>>> rename the files manually).
>>>
>>> FWIW I think this approach is good, but since Gnus doesn't even emit a
>>> warning currently when creating a group with % in its name, I don't
>>> think breaking these groups is a good idea.
>>>
>>> Daniel
>>>
>
> I've been using this since then, on master, with no problems. Let me add
> to my earlier reasons for being confident about this not breaking
> existing setups:
>
> James Thomas wrote:
>
>> I think only one of these combinations is likely to be a problem in
>> practice: groups such as [Gmail]/Drafts. I've never seen a % in a
>> group name. The cache wouldn't work for one with / anyway (this bug)
>> and as far as the agent is concerned, none of the Gmail groups with
>> spaces in them work anyway (bug#65467: note that the patch on this is
>> also needed for the agent to work on these groups with /). I haven't
>> used nnmh or nndiary but I don't think they normally use group names
>> with '/'.
>
> The only ones with '/' (and no spaces) I know of are the Gmail groups,
> namely:
>
> [Gmail]/Bin
> [Gmail]/Drafts
> [Gmail]/Important
> [Gmail]/Spam
> [Gmail]/Starred
>
> ...which are unlikely to be agentized because of their nature (though
> ideally the patch at bug#65467 ought to be applied as well, after this).
>
> Moreover, getting Gmail to work with Gnus requires a paid account and a
> complicated setup with OAuth2 (AFAIK, because I use one) which only few
> people are likely to have managed.
>
> Lastly, the fix for such an unlikely existing setup is a simple rename
> of the directory: say, from [Gmail]_Drafts to [Gmail]%2FDrafts.
Thanks, I've now applied this, and am closing the bug. Sorry this took
so long -- I kept thinking I would dive a little deeper into the nnmail
file/directory shenanigans and get a better grasp on the internals, but
obviously was not finding the time. In it goes!
Eric
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
Tags: patch
Reproduction steps:
- Setup Gnus with any group name having a slash ('/') such as
"[Gmail]/Drafts" or an Atom feed (they usually have slashes) using the
patch in bug#66188.
- Press '*' on a message in the group.
- Do (info "(gnus) Creating a Virtual Server")
- Open the above from the Server buffer; RET on the new group fails.
A patch is attached. I couldn't find the problematic commit or its
original branch (where it was a consolidated merge from) but
'gnus-use-long-file-names' is apparently not meant for backends: it
can't even be customized with that 'not-cache' option. I think this is
the right way to solve it: the other lines removed in this patch are
even older, but they were never being called due to the above reason.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0) of 2024-02-20 built on
user-Inspiron-15-5518
Repository revision: 466800591c2bd674b0b967205147d7519da7e1a4
Repository branch: nnatom-master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Ubuntu 22.04.3 LTS
[0001-Make-gnus-cache-work-with-group-names-having.patch (text/patch, attachment)]
[Message part 6 (text/plain, inline)]
--
This bug report was last modified 1 year and 47 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.