bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: James Thomas
Subject: bug#69517: [PATCH] Make gnus cache work with group names having '/'
Date: Mon, 11 Mar 2024 03:02:01 +0530
User-agent: Gnus/5.13 (Gnus v5.13)

(This is an interim untested opinion before I can backup my existing
messages and verify it...)

Eric Abrahamsen wrote:

> Thanks for reporting this! Obviously something is wrong here, but I get
> different results from your reproduction recipe (I'm running master):
> when I create the cache nnml server and hit RET on it, I get:
>
> K      1: nnml:left.right
> K      1: nnml:left/right
>
> I am able to subscribe to both groups. When I return to the *Group*
> buffer, I can enter the version of the group with the ".", and read the
> cached article, while attempting to enter the version with the slash
> gives me "Invalid group (no such directory)".
>
> On disk, the "News/cache/active" file starts out with the version with
> the ".", and after I create the extra cache server it contains both, it
> looks like:
>
> "nnml:left.right" 1 1 y
> "nnml:left/right" 1 1 y
>
> Meanwhile, the directory structure "News/cache/nnml:left/right/1" is
> created.
>
> The "." in the active file comes from `gnus-cache-generate-active`, and
> that mechanism seems to be working fine, at least in my case -- do you
> not see that version of the group?

`gnus-cache-generate-active` seems to be run if the active file doesn't
exist already (i.e. at the very start when creating a server): I was
adding new groups to an existing server. If my guess is right, that
first line with the dot being generated is a way of reversing the
earlier 'dot -> slash' when turning a group into a directory name. That
should be fixed as well if group names with slash have to be supported.

> while attempting to enter the version with the slash gives me "Invalid
> group (no such directory)".

Could you try entering it with this patch applied?

>
> To be honest I have no idea what's happening in `gnus-cache-file-name'.
> I'd be hesitant to remove all that code without understanding it better
> And I don't think we can argue that that code is "dead" just because it
> is behind an option value that isn't one of the customization options.
>
> Anyway, it would be good to first know why you're not seeing the "."
> version of the offending filename, and then I guess try to work out
> what's going on with the file names. It kind of looks like a collision
> between two different mechanisms -- one that translates "/" to "_" to
> prevent unwanted filesystem hierarchies, and one that translates between
> "/" and "." in order to convert newsgroup-name dot hierarchies into
> filesystem hierarchies. In this case, it seems like "long names" and
> newsgroup hierarchies shouldn't be applicable at all.

I think if the original group name contains dots, that should be part of
the hierarchy. But not slashes.

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

Hmm..

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

I think this patch is on those lines, isn't it?

Regards,
James





reply via email to

[Prev in Thread] Current Thread [Next in Thread]