Declined easy suggestion: update error message for "the process cannot access the file"

[Claire_CJS]

"The process cannot access the file because it  is being used by another process."

How about telling us which file it cannot access?
I'm in a situation where i have to turn echo on and debug a bunch, to see which file it's talking about.
Why not just tell us?
Seems like a very easy improvement!

 

[vefatica]

Doesn't the error message also give a batch file line number?

 

[Claire_CJS]

And that line number could easily be a wildcard

But also, it could be involving names that are environment variables that one cannot discern the value of by looking at the bat file. It could be involving a command that is itself an environment variable so looking at the line tells you nothing. Plenty of situations where one is not going to easily know.

But also... Wildcard. If it's "copy /u *", and a file fails, no way to know. Kinda neuters that secure feeling of knowing what your command did. I updated all my files, except one. Which one? I don't know. There were 4,000 it could have been. I could go on an investigation with timestamps...... I can examine open filehandles... Or like, the error message could say what file it's talking about and i'd just know right away how to handle the problem as fast as possible.

 

[Charles Dye]

I think this would be trivial to add, if you know where to add it. Which command or function is giving you that error?

There must be thousands of places in the code where TCC checks for and reports errors. Tens of thousands?

 

[Claire_CJS]

Well in this case i'm just talking about one? :D

 

[Claire_CJS]

Just really thwarts my backup process to have one file not backed up and not be sure which. I guess I could loop the files one file at a time but that just seems nuts and way slower.

 

[Joe Caverly]

Would the @filelock function be of use?

Ref: https://jpsoft.com/help/filelock.htm

Joe

 

[Charles Dye]

Would the @filelock function be of use?

Ref: https://jpsoft.com/help/filelock.htm

Yes, if she knew the name of the locked file.

 

[rconn]

"The process cannot access the file because it  is being used by another process."

How about telling us which file it cannot access?
I'm in a situation where i have to turn echo on and debug a bunch, to see which file it's talking about.
Why not just tell us?
Seems like a very easy improvement!

That error is a Windows error, not a TCC error. Depending on what command you were executing, TCC probably doesn't know what file couldn't be accessed. (For example, if you were doing a COPY, TCC doesn't know if Windows is complaining about the source or the target file).

In all the cases I know of where TCC knows the failing filename, it will display it.

 

[rconn]

And that line number could easily be a wildcard

I have no idea what you mean by that -- how could the line number be a wildcard?

But also, it could be involving names that are environment variables that one cannot discern the value of by looking at the bat file. It could be involving a command that is itself an environment variable so looking at the line tells you nothing. Plenty of situations where one is not going to easily know.

This is why BDEBUGGER exists. Run your batch file in the debugger and you will know all of that.

 

[rconn]

Just really thwarts my backup process to have one file not backed up and not be sure which. I guess I could loop the files one file at a time but that just seems nuts and way slower.

Unless you're redirecting output to nul, I don't see the problem.

If you're doing a COPY, TCC will write the source file + target file to STDOUT. If the COPY fails, the next line (written to STDERR) will contain the error message. Then just look at the previous line, and you'll know that it was either the source or the target.

Also see ON ERROR, which could retrieve the filenames & display and/or log a custom error message.

 

[Claire_CJS]

Also see ON ERROR, which could retrieve the filenames & display and/or log a custom error message.

I have a huge blind spot for the "on" stuff, which I somehow missed for decades.

Thanks, I'll have to look into that. The "on" stuff is a huge blind spot for me.

[I do wish the help page for on error had a more concrete example like this]

Unless you're redirecting output to nul, I don't see the problem.

Which I am. There are situations where I don't want lists of filenames filling up my screen because there are thousands. If an error message was buried in those thousands of lines, I would never see it in a million years.

So I either use copy/q to suppress the list, or i pipe it through a script i have that makes a randomly colored dot per file copied

Neither of those situations will display the filenames (maybe copy /q does on error?), so the error message is not solveable.

And going back and doing it again requires it being a reproduceable situation, which it often is not (temporary file locks and such).

I've moved on from countless errors over the decades without ever knowing what they were because of this. The amount of effort to include the filename vs the amount of effort of anyone in my situation seems rather disproportionate IMO

If you're doing a COPY, TCC will write the source file + target file to STDOUT. If the COPY fails, the next line (written to STDERR) will contain the error message. Then just look at the previous line, and you'll know that it was either the source or the target.

Which is pretty useful for the standard use case!

But less so with /q and/or redirecting STDOUT to nul

Anyway.. I did figure out the file. It was Charles's StripAnsi.dll that won't read as long as the plugin is loaded, which seems..... excessive. I'll have to talk to Charles about that.