SBSE____.??? files (the SBSE____ part is fixed, the ??? part is 'agile'*) are files used in our SafeCopy process:
Modify profile > Expert mode > Copy/Delete > Advanced > 'Make safe copies....'
Press F1 with the Advanced settings page open for contextual Help on what the process does and why it is usually a good idea.
Normally the profile (program) will rename them to the 'live' file-name, and/or delete them again if any errors mean that cannot be performed. Hence, the file/s still being there are symptomatic of not only a run which encountered errors, but where a connection to a device was lost, or the device refused to delete them (or failed to), or denied they were there when we tried. (NAS boxes, FTP servers and combinations of the two are the usual culprits for the latter issues.)
There's no way for us to tell from here if they represent data 'caught in mid-copy' (which you don't otherwise have copies of), sorry. But as the software should pick up differences between the two sides when scanning (running a profile, stage-1) and try to resolve them, it may well be that any data they represent has been re-copied by now anyway (assuming there has been at least one run of that profile since).
You can probably safely delete them, but we can't actually guarantee that, however we can confirm the profile in question won't reference them again (they're not 'required' by the profile now, if the run that created it/tem has stopped running now).
* hence you are unlikely to see any other .ORM files, except by random chance
Modify profile > Expert mode > Copy/Delete > Advanced > 'Make safe copies....'
Press F1 with the Advanced settings page open for contextual Help on what the process does and why it is usually a good idea.
Normally the profile (program) will rename them to the 'live' file-name, and/or delete them again if any errors mean that cannot be performed. Hence, the file/s still being there are symptomatic of not only a run which encountered errors, but where a connection to a device was lost, or the device refused to delete them (or failed to), or denied they were there when we tried. (NAS boxes, FTP servers and combinations of the two are the usual culprits for the latter issues.)
There's no way for us to tell from here if they represent data 'caught in mid-copy' (which you don't otherwise have copies of), sorry. But as the software should pick up differences between the two sides when scanning (running a profile, stage-1) and try to resolve them, it may well be that any data they represent has been re-copied by now anyway (assuming there has been at least one run of that profile since).
You can probably safely delete them, but we can't actually guarantee that, however we can confirm the profile in question won't reference them again (they're not 'required' by the profile now, if the run that created it/tem has stopped running now).
* hence you are unlikely to see any other .ORM files, except by random chance