Radmind

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

I've attached a patch that applies against CVS head. Once applied,
running the server with -R will cause it to remove transcript and files
from radmind/tmp when uploading one that conflicts. A message is logged to
syslog at the info level, which isn't logged by default in OS X.

Please test this patch and let me know how it works for you.
File Added: remove-temp-files.patch

I would be happy to just have the server remove transcripts and files for
loadsets whose upload was incomplete or otherwise failed (perhaps after a
timeout).

I haven't used any of the PAM options with Radmind and don't know if this
in any way assists with user's ability to overwrite loadsets upon lcreate.
However, whether or not enabling PAM support allows more authentication and
authorization options, having fine-grained permissions for various actions
could be a benefit. I can see this being true especially in larger Radmind
installations where federation is a requirement or desirable because of the
number of admins -- and this is a use case that config file includes help
address, so there has been work in this area.

I think that such and option should be, by default, off -- and able to be
enabled via some conf file on the server (or by a flag when starting
radmind on the server). Sure, there exists the possibility that data
deletion might become time consuming, but the person invoking the option
using lcreate would be cognizant of that (she or he put the files up there
and already has a sense of what's in the /tmp directories).

lcreate doesn't overwrite existing transcript for security reasons; if one
person can remove a transcript, anyone could.

If this were to be implemented, it would be an option to the server that
was off by default. When turned on, existing transcripts would be
overwritten. As there could be substantial amounts of data to remove, this
process could take some time before allowing the new transcript and
associated files to be stored. Would that be an acceptable solution?

I agree with this, as it always requires a trip to the server to delete
transcripts I've uploaded before I discovered an error or omission.