etd timeout needed

[varenius]

The following scenario has now happened so many times that I feel something ought to be done:

• etc transfers to etd
• etc disappears (e.g. reboot)
• etd continues to keep write-lock in place for last file during transfer
• etc cannot resume transfer

on the etc side, I am greeted by:

[...]
2021-10-26 19:46:14.65: [int main(int, const char* const*)] Retry #2 (#2 for this file), go to sleep for 10s
2021-10-26 19:46:24.65: [int main(int, const char* const*)] PUSH Resume /mnt/vbsmnt/vo1287_ow_288-0157_1 -> /vgos/vg01/VO1287/Ow/vo1287_ow_288-0157_1
2021-10-26 19:46:24.65: [virtual etdc::result_type etdc::ETDProxy::requestFileWrite(const string&, etdc::openmode_type)] ETDProxy::requestFileWrite/sending message 'write-file-Resume /vgos/vg01/VO1287/Ow/vo1287_ow_288-0157_1
' sz=60
2021-10-26 19:46:24.93: [int main(int, const char* const*)] Got exception: assertion error: src/etdc_etdserver.cc:935 [status_s=="OK"] requestFileWrite(/vgos/vg01/VO1287/Ow/vo1287_ow_288-0157_1) failed - assertion error: src/etdc_etdserver.cc:198 [pathPresent==false] requestFileWrite(/vgos/vg01/VO1287/Ow/vo1287_ow_288-0157_1) - the path is already in use
2021-10-26 19:46:24.93: [virtual bool etdc::ETDProxy::removeUUID(const etdc::uuid_type&)] ETDProxy::removeUUID/sending message 'remove-uuid rLTMxxDY6P7K0Hw
' fd=3
2021-10-26 19:46:25.21: [etdc::etd_state::~etd_state()] ~etd_state/need to wait for 0 threads

One possible solution appears to be for the receiver side to remove the file and restart etd. I'd very much like to avoid this sort of action. If the etd side had a timeout to release the file-lock of, say, 15 minutes? Then one could try again.