Swapping files corrupts multi-owner permissions silently

[korydraughn]

Known applications that do this are:

• Vim
• Nano

[trel]

Possible workaround could be to 'cache' permissions of 'similarly named files' for some amount of time, and detecting a set of known patterns of application behavior... restore the original permissions on the swapped tempfile-turned-realfile.

This is a problematic approach as it's specific to particular programs and their behavior...

Please share any other strategies for the NFSRODS server to 'know' a new file is a tempfile created for the purposes of replacing the realfile by an application on the other side of the mountpoint.

[michael-conway]

Is the implementation calling 'rename' under the covers on the files? I can dig into the code, but I'm wondering how this swapping takes place in terms of visibility to the underlying iRODS code. I'm confused on this issue, so knowing the call chain that occurs would be the best first step!

[trel]

Kory can be more specific... but as I understand it...

• 1 - data.file exists in iRODS, and has multiple permissions set on it (alice/own, bobby/read, etc.)
• 2 - alice opens data.file in vim
• 3 - vim creates data.file.swp with only alice/own permission
• 4 - vim, on save (or also at other times(?)), replaces data.file with data.file.swp
  • not sure if this is 'unlink data.file && rename data.file.swp -> data.file' OR
  • just 'rename data.file.swp -> data.file' directly
• 5 - data.file now only has alice/own permissions, bobby can no longer read the file

[michael-conway]

That's what I'm after, whether there is a definite API 'signal' here. Maybe if we are picking a hackfest day at RENCI we could sit and instrument this before cutting a solution? It's been a while since I dug into that code...