Filter causing file to be copied with 0 bytes?

[Ben Amada]

Hello. Yesterday I added a filter to my script to exclude a folder:

filter "-.\newsletters\issues"

The folder appeared to be excluded and everything appeared to be working correctly.

Today, a file in the root of the folder comparison (web.config) changed and when I ran the script to sync/copy files. BC correctly determined web.config to have changed, but after it copied it over, it was a 0 byte file in the destination (it's a 45KB file in the source folder). I ran the sync a couple of more times, and it remained at 0 bytes. I then commented out the filter, ran the script again, and it copied over correctly.

Is this possible? Is the syntax on my filter correct?

Running BC Version 4.2.2 (build 22384)

Any ideas are appreciated - many thanks.
Ben

[Aaron]

Hello,

No, the filter above shouldn't have that kind of impact. Filtering determines if the item is visible in the folder compare. If excluded, it would not show up unless you toggle on Suppress Filters (where Excluded items then appear in a teal color). The above filter text wouldn't exclude the item in the base location, and if you saw the item visible and not teal, then there were no other filters excluding it. You could verify this in the graphical interface by loading your two folders as base folders, and copying/pasting the filter text (without quotes) into the Filter Toolbar dropdown in the main view.

If sounds like you are running from a script. Perhaps you have a syntax error elsewhere in the script file? However, if the file was attempted to be copied, and copied as 0, I would expect an error rather than script issue. It may have been a transient network error, or something along those lines, where repeated attempts then allowed it to eventually copy correctly. What type of device is either side of the sync? Are either remote locations (ftp, network share, etc)?

If your script does not have it yet, add as the very first line:
log verbose "c:\bclogs\bclog.txt"
this will save a verbose log of any actions that take place during that script call.

[Ben Amada]

Hi Aaron,

Thanks for confirming the filter was not causing the issue. I was thinking the same... it wouldn't be logical.

It turns out I did have verbose logging enabled and I found an error in each of the 3 or so times I ran the script:

8/29/2017 2:06:31 AM Unable to copy G:\xxxxx\web.config: The process cannot access the file because it is being used by another process
8/29/2017 2:06:31 AM Failed to copy 1 items. Completed in 0.03 seconds.

The question is, what process was using the web.config file. It's either IIS or I did have the web.config file opened in Notepad++ at that time, but at least AFAIK, I don't believe Notepad++ prevents files from being updated while opened in Notepad++. After commenting out the filter in the script and running it again when the web.config file did copy over successfully, I don't remember now if I had closed the web.config file in Notepad++. And to answer your question, the script is copying files from one drive to another drive on the same machine.

Do you have any suggestions on how to avoid or remedy this situation? Specifically I'm thinking:

(a) in this case, the web.config file essentially became "corrupt" in that it lost all of it's contents, going down to 0 bytes. Is there anything I can do to avoid that?

(b) probably not possible but can BC detect one of the files to be copied is being accessed by another process, and if so, fail early and don't start copying any files to avoid a situation where some of the files get synced and some don't.

(c) when there's an error like this, does BCompare.exe return a different Exit code? i.e. a non-zero (0) exit code. The BC script is running from a continuous deployment system and if it does return a non-zero exit code, I may be able to configure it to consider the deployment a failure so we get notified there is a problem.

Any thoughts/ideas are appreciated - thank you.
Ben

[Aaron]

Hello,

If you run into one of these locks, does repeating the transfer still cause the error? If so, what behavior do you see if you then try the same transfer in Windows Explorer?

We don't have a method to pre-detect the error (or, similar to Access Denied, we could overlay an icon and show the error on load). We do have a wishlist item to help retry after hitting an error like this; would that help in this scenario?

[Ben Amada]

Hi Aaron,

Since the other day, I haven't run into one of these locks again. Today I intentionally made a change to the web.config file to force BC to update it, and I had the web.config file opened up in Notepad++ but there was no locking problem. Don't know for sure, but it could be IIS that had the file opened. When I had the locking the other day, I did run the BC script 2 more times and the same locking problem occurred (there were 3 instances of this logged). So at least in this instance, if BC were to automatically retry copying the file, it would have likely failed again on the retries.

I'll keep an eye on the verbose error log to see if this happens again and I may do some more testing to try and make it happen again, i.e. to see what process has a lock on it and see if there's anything that can be done to detect that beforehand (before I run the BC script) or see if I can force the lock to be released.

I appreciate your time. If I learn anything new, I'll post back.

Regards,
Ben