Re: [Tools-implementation] Fwd: Emacs lock files in rfc rsync

[Robert Sparks <[e-mail]>]

For the short term, I propose that we delete and resync what's at our 
::rfc sync point so it matches the rfceditor exactly.

Does anyone know of a reason not to do that?

We can then discuss removing it as an exposed sync point.

RjS

On 2/4/21 5:40 PM, Glen wrote:
> Something we should review in our next meeting.   I'll provide the 
> technical details at that time.  (Roman, sorry I forgot to cc you on 
> the original reply, I missed your presence in the header until after I 
> hit send, but this is the same email reply below.)
>
> Glen
>
> -------- Forwarded Message --------
> Subject: Re: Fwd: Emacs lock files in rfc rsync
> Date: Thu, 4 Feb 2021 15:38:02 -0800
> From: Glen <[e-mail]>
> Organization: AMS
> To: Eric Rescorla <[e-mail]>
> CC: Sandy Ginoza <[e-mail]>, Alice Russo <[e-mail]>, 
> John R Levine <[e-mail]>
>
> All -
>
> In the interest of time, I am just grouping everyone together and 
> replying to this thread directly.
>
>>> From: Eric Rescorla <[e-mail]>
>>> Subject: Emacs lock files in rfc rsync
>>> Date: February 4, 2021 at 1:06:27 PM PST
>>> To: RFC Editor <[e-mail]>, Roman Danyliw 
>>> <[e-mail]>
>>> Hi folks.
>>> I just rsynced the rfc directory and I see that several of the files 
>>> have Emacs lock files [0] associated with them:
>>> lrwxrwxrwx  1 ekr  staff  39 Mar 16  2016 .#bcp-ref.txt -> 
>>> [e-mail].16317:1457089460
>>> lrwxrwxrwx  1 ekr  staff  39 Mar 27  2019 .#rfc-index.xml -> 
>>> [e-mail].12369:1551880913
>>> Aside from just creating problems when someone else tries to edit 
>>> the files in Emacs, it suggests that you might have some kind of 
>>> process problem, because this material should be machine generated, 
>>> and people shouldn't be editing it in a way that the directories are 
>>> just raw synced to the server.
>
> Eric -
>
> My apologies, but you are not using the authoritative source for your 
> rsync.  You stated that you're using:
>
>> rsync.ietf.org::rfc
>
> That is the IETF's legacy mirror of RFCs.  I do not refer or recommend 
> it.  It appears to be a legacy configuration, and to have some 
> duplication in it.  Moreover, for reasons unknown to me, it is being 
> rsynced without the --delete option, which means it will retain every 
> file it ever saw during any prior rsync.  That is why you are seeing 
> those files.  They existed at some interval in the past; they do not 
> exist (on the RFC servers) now.
>
> I will raise this with the Tools Implementation Team to see if (a) 
> this behavior should change or (b) the IETF copy should be removed or 
> referred.  Removing files from it, or making changes to it, are not 
> things I can "just do" on my own in my role.  Note that they are 
> working on other, larger projects right now, so this will need some 
> time before it can get attention.
>
> In the meantime, I recommend that you change your configuration to 
> rsync your RFCs from rfc-editor.org:: , which is the authoritative 
> source for RFCs.  They have a catalog of options, one of which will I 
> hope suit:
>
> # rsync rfc-editor.org::
> everything-ftp  Everything FTP
> refs            XML references for RFCs (for use with xml2rfc)
> rfcs            Contents of in-notes including subdirectories std, 
> bcp, fyi, and ien
> rfcs-text-only  Only the text files from the directories in [rfcs]
> rfc-ed-all      Entire repository (excluding internet-drafts)
> internet-drafts Internet Drafts
> ids-text-only   Only text files from the Internet Drafts mirror
> rfcs-pdf-only   PDF versions of ASCII RFCs to ensure correct page 
> breaks, etc
> rfcs-exclude-json       Contents of [rfcs] excluding JSON files
> rfcs-json-only  Only the JSON files from the directories in [rfcs]
>
> In the meantime, the files you referred to, which may exist on the 
> legacy IETF copy, will not be removed, nor will any other changes be 
> made to the IETF copy, until the Tools Implementation Team can carve 
> out time to review this and determine the correct solution.
>
> I will send the relevant information to them now, to get this on their 
> radar.
>
> Thank you,
> Glen
>
>
>
>