bug#69517: [PATCH] Make gnus cache work with group names having '/'

[James Thomas]

Daniel Semyonov wrote:

>>>>>> James Thomas writes:
>
>     > 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).

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 '/'.

Regards,
James