We had some few cases of users losing their files, while being edited in some editor (seems mostly ones using glib like gedit and geany). From what we can understand, the file is kept open in writing for a long time withoug any writing (not sure if the software is to blame) by the eos client, and when the eos client stops, or the connection goes timeout (because of xrd.timeout idle directive), the FST says info="deleting on close" reason="client disconnect", file has been cleaned because of a client disconnect. Then the file is removed.
I suppose that in some cases this is a correct way to operate for coherence, but in such situation it is counter-intuitive, and the users would probably prefer to keep the file in an incomplete state, or the previous content when it is modified, rather than losing the file. We unfortunately never managed to systematically reproduce ths issue, so it might depend on the situation.
Is it something that can be changed with some parameters to avoid the FSTs triggering a file delete ? On other file systems, if a file is partially written, we can retrieve these data.
Versions are 4.5.15 for MGM, 4.5.17 for FSTs. The client is eosd in the last case.