b4 message ID shortening

b4 message ID shortening

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

When generating filenames to save messages b4 am looks like it truncates
the message ID to generate the default filename (or possibly uses a
portion of the date now I think about it, I didn't read the code).  For
example

   https://lore.kernel.org/r/20200320232515.GA24800@embeddedor.com

results in a mailbox

   20200320_gustavo_embeddedor_com.mbx

which is all well and good except if you also try to save:

   https://lore.kernel.org/r/20200320232556.GA24989@embeddedor.com

it generates the same filename and silently overwrites the first
mailbox.  Using b4 mbox avoids this as it generates files using the full
message ID such as

   20200320232515.GA24800@embeddedor.com.t.mbx-thread

which avoids collisions.

FWIW my workflow is currently to save a bunch of mailboxes into a
directory then throw them at a script to do some testing & apply them if
that works.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]

Re: b4 message ID shortening

[Konstantin Ryabitsev]

On Mon, Mar 23, 2020 at 12:54:56PM +0000, Mark Brown wrote:
> When generating filenames to save messages b4 am looks like it truncates
> the message ID to generate the default filename (or possibly uses a
> portion of the date now I think about it, I didn't read the code).  For
> example
> 
>    https://lore.kernel.org/r/20200320232515.GA24800@embeddedor.com
> 
> results in a mailbox
> 
>    20200320_gustavo_embeddedor_com.mbx
> 
> which is all well and good except if you also try to save:
> 
>    https://lore.kernel.org/r/20200320232556.GA24989@embeddedor.com

It doesn't really shorten it as much as it tries to create a descriptive 
enough "slug" that is supposed to help you identify the content by just 
looking at your dir listing.  How about we throw in the patch/cover 
title, e.g, for that particular case the slugs would be:

20200320_gustavo_spi_spi_s3c24xx_replace_zero_length_array_with_flexible_array_member.mbx

and

20200320_gustavo_spi_spi_fsl_lpspi_replace_zero_length_array_with_flexible_array_member.mbx

This used to be the scheme in early revisions, except filenames ended up 
being freakishly long. An option is to truncate them if they go over a 
certain length.

> it generates the same filename and silently overwrites the first
> mailbox. 

I can do the -1.mbx, -2.mbx, etc when we find existing files, but I'm 
worried this will be annoying for people who are rerunning the same 
series for the purposes of adding other flags. On the other hand that 
would be safer.

If we have more disambiguated .mbx names, would you still prefer not to 
overwrite existing .mbx files?

-K

Re: b4 message ID shortening

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

On Mon, Mar 23, 2020 at 12:38:59PM -0400, Konstantin Ryabitsev wrote:

> It doesn't really shorten it as much as it tries to create a descriptive 
> enough "slug" that is supposed to help you identify the content by just 
> looking at your dir listing.  How about we throw in the patch/cover 
> title, e.g, for that particular case the slugs would be:

> 20200320_gustavo_spi_spi_s3c24xx_replace_zero_length_array_with_flexible_array_member.mbx

> and

> 20200320_gustavo_spi_spi_fsl_lpspi_replace_zero_length_array_with_flexible_array_member.mbx

> This used to be the scheme in early revisions, except filenames ended up 
> being freakishly long. An option is to truncate them if they go over a 
> certain length.

That looks good for my usage, long filenames aren't a concern for me but
I can see some people might not like them (perhaps a configurable
length, or perhaps that's overthinking it?).

> > it generates the same filename and silently overwrites the first
> > mailbox. 

> I can do the -1.mbx, -2.mbx, etc when we find existing files, but I'm 
> worried this will be annoying for people who are rerunning the same 
> series for the purposes of adding other flags. On the other hand that 
> would be safer.

Yes, and indeed I do use the overwriting behaviour myself if for example
new tags come in before I actually process the mailboxes.

> If we have more disambiguated .mbx names, would you still prefer not to 
> overwrite existing .mbx files?

I think it's the silent bit as much as the overwriting bit that caught
me out - I didn't notice that it had overwritten the existing mailbox,
if it had said something about replacing an existing mailbox I'd
hopefully have seen that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]

Re: b4 message ID shortening

[Konstantin Ryabitsev]

On Mon, Mar 23, 2020 at 05:05:12PM +0000, Mark Brown wrote:
> > It doesn't really shorten it as much as it tries to create a 
> > descriptive enough "slug" that is supposed to help you identify the 
> > content by just looking at your dir listing.  How about we throw in 
> > the patch/cover title, e.g, for that particular case the slugs would 
> > be:
> 
> > 20200320_gustavo_spi_spi_s3c24xx_replace_zero_length_array_with_flexible_array_member.mbx
> 
> > and
> 
> > 20200320_gustavo_spi_spi_fsl_lpspi_replace_zero_length_array_with_flexible_array_member.mbx
> 
> > This used to be the scheme in early revisions, except filenames ended up 
> > being freakishly long. An option is to truncate them if they go over a 
> > certain length.
> 
> That looks good for my usage, long filenames aren't a concern for me but
> I can see some people might not like them (perhaps a configurable
> length, or perhaps that's overthinking it?).

Yeah, let's try to be more disambiguatey without piling on too many 
config options. I pushed the above change.

> > If we have more disambiguated .mbx names, would you still prefer not 
> > to overwrite existing .mbx files?
> 
> I think it's the silent bit as much as the overwriting bit that caught
> me out - I didn't notice that it had overwritten the existing mailbox,
> if it had said something about replacing an existing mailbox I'd
> hopefully have seen that.

I'm hoping that with the current change this will be a rare enough case 
that it doesn't cause problems. The output is already fairly verbose, so 
I'm wary of adding any more warnings to it.

-K

Re: b4 message ID shortening

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Mon, Mar 23, 2020 at 02:04:51PM -0400, Konstantin Ryabitsev wrote:
> On Mon, Mar 23, 2020 at 05:05:12PM +0000, Mark Brown wrote:

> > > This used to be the scheme in early revisions, except filenames ended up 
> > > being freakishly long. An option is to truncate them if they go over a 
> > > certain length.

> > That looks good for my usage, long filenames aren't a concern for me but
> > I can see some people might not like them (perhaps a configurable
> > length, or perhaps that's overthinking it?).

> Yeah, let's try to be more disambiguatey without piling on too many 
> config options. I pushed the above change.

Thanks!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]