dealing with transferTemp files

jtomejtome Member Posts: 11
We've got users spread across the US and soon other continents using Adept Desktop and a VPN connection back to our private cloud.  While the VPN has been very good it's not perfect.  We occasionally get a call/ticket that folks cannot check in a file (Message # 4111) that we've found to indicate that an earlier Check In was interrupted by some network connectivity issue between client and server.

The solution has been to go looking for a file with the extension .transferTemp of the same name as the file(s) that reported the error and then deleting that temporary file.  To be clear, this is looking in the "back door" of the Vault not through the Adept client.  Once the file is cleared the user can check the file back in.  Once or twice the file was locked and I just waited it out overnight and was able to delete the file in the morning.

It's not a difficult or time-consuming fix, but it's another thing that has to be done in a day that is already full #ImBusyToo

Thanks for reading the setup to my question... So has anyone come up with a slick way of dealing with these files?

I'm about to write up a specification to an in-house developer to give me a program that periodically looks for these through the Vault back door, determines if the files have been static for say at least an hour (indicating that its not likely and active Check In that's underway) and then deletes the offending file and probably writes some information to a log and/or into a notification email.

Another question... Anyone at Synergis have an explanation why AFS couldn't do what I just described as part of it's typical duties?  Or is there a good, valid reason why I shouldn't do what I've described above?
James Tome
Sign In or Register to comment.