"Failed to record run time" failures when moving temp file

[derrickstolee]

We are getting failures when trying to record our ".time" files. Likely, these are permissions issues for a shared drive or users using Windows Server 2016 who cloned with admin permissions.

The priority here is probably low. We likely are running the loose objects step and packfile maintenance step a bit too aggressively for these users.

What's the right fix here?

[kewillford]

I know there are some items #1579 and #1580 that relate to this but I was thinking that if this is only trying to record the ".time" file, it would be easiest to write the file to a location that the user has permissions to if it fails. There shouldn't be any security concerns for this one file. Might mean that we are checking 2 places for the most current ".time" file but seems a lot easier that messing with ACLs and trying to get that right.

[derrickstolee]

Interesting. We could have the mount-based maintenance check something local to the enlistment, say in the .gvfs directory instead of just the shared object cache. This wouldn't prevent multiple mounts that share a cache from each running the maintenance quickly, but we could at least prevent a single mount from running it too often.

I wonder if we should just defer to those existing items, and note that they have not risen to priority yet. In the meantime, I can probably clear these warnings from our alerts, at minimum.

[kewillford]

We could also use somewhere like the user's AppData folder (a known location that the user will have access to) if we want a shared location.