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

[Glen <[e-mail]>]

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