Don, I know you told me you couldn't add a tweak which made all scripted file ops occur in the foreground and be blocking, as they were before XYcopy. But couldn't you add a tweak that forces a "Setting('BackgroundFileOps', 0);" before every script? That seems like it would be incredibly easy to do; like most things when you cannot see the source.
About this issue, somewhat. I understand TheQwerty's request, because to be honest I only use background processing on copy operations because I don't want to have to go through all my scripts (many of which do do move operations, and require for their execution to only continue upon completion of said file (move) operation) right now to add such a thing. I'm lazy, I know.
But there is something I wish for, because right now the "odd" thing with BackgroundFileOps (as param for setting) is that it's an "incomplete" option, since unlike all the other ones, it relies itself or other options (Apply to).
What I mean is, if today I write a script and I need to make sure there won't be no background processing, cause I need the script to continue its execution only after it's done, I can do that (setting 'BackgroundFileOps', 0;) just fine. (Side note: Ideally, when we have CEA if we could add a script to be executed upon completion of a background job, that would be awesome. As in, a script to be executed when a specific bg job is completed, or where we have the job #ID and can use that...)
Back on topic, now let's imagine I have a script and I need to have a file operation in the background. Well, I can't. Oh sure, I can do a setting 'BackgroundFileOps', 1; but that doesn't mean anything at all, really. It means "process in the back, IF the user said so in his "Apply to" settings). I wish the script could force the operation to be processed in the background. The whole point of setting, to me, is to be able to know/set what's gonna happen, regardless of the current user-settings. We can if we want to disable bg processing, but not the other way around.
For example, I have have bg processing enabled for Copy only, for reasons stated previously, but I'd love a script that would force a move operation to be processed in the background (meaning the script should be able to "by-pass" the Apply to settings). Maybe a new setting should be added, alongside BackgroundFileOps, such as BackgroundedFileOps. (Although that's probably somewhat asking for confusion... I blame Don, though, who decided to call FopInBackground BackgroundFileOps.)
Either that or we should have the current BackgroundFileOps work as its brother in the INI does, thus allowing the script to really know what will happen, and maybe a new value (for use with setting only) would need to be added, meaning "use user setting".
admin wrote:Ah yes, confirmed. But I don't see how this could be a very recent error. From the source code it looks like it was born 20090801.
I don't know when it first started happening, but it's been in the last month or so. I only noticed it because of jacky's updater script (which makes me surprised no one else reported it).
Well, for the record I use that script too, and never had any crash... so there must be another factor somewhere or something.