I posted this question on StackOverflow a couple of weeks ago at, but there are no comments or answers there (and it is perhaps more relevant here): https://stackoverflow.com/questions/78703413/how-to-fix-semaphore-timeout-period-has-expired-when-copying-some-specific-jav
For the past month, on the network at work, we have encountered "semaphore timeout period has expired" errors when copying some specific JavaScript files to a server (most files copy successfully without any issues).
The problem was first encountered when publishing a project from Visual Studio 2022 on a Windows 10 workstation to an internal web server. The same problem can be reproduced when using COPY from a command prompt, or ROBOCOPY from a command prompt, or doing a copy-and-paste operation between File Explorer windows. It can be reproduced from several different workstations, and copying to any of several different servers on the network. It can also be reproduced copying from one workstation to another workstation. It can be reproduced on multiple workstations (all running Windows 10) and multiple servers (running Windows Server 2012 or 2016). The machines are all up-to-date with Windows updates, network drivers, etc.
The problem is a failure to copy ONLY some specific files from a workstation to a server on the same work network.
The error only occurs for JavaScript files, and only for a few specific JavaScript files; most JavaScript files copy successfully. The JS files that fail to copy (in my testing) are unmodified third-party (Bootstrap-related) files.
For the ".js" files that fail to copy, if I change the file extension to ".txt" (with no change to the content), then the copy of that file succeeds.
For the ".js" files that fail to copy, if I edit the content of that file (changing only comment sections in the file) and save it (with the same name and extension), then the copy of that file succeeds.
We have tested this while the security group temporarily disabled the anti-virus and the firewall on both the workstation and server used for the test; and the problem still occurs with any or all of these disabled. Analysis of Wireshark logs hasn't found a cause of the problem.
When this error occurs, there are several SMB-related errors logged in the local Event Viewer logs on both the client and server machines.
There is a bit more detail in the post on StackOverflow.
Does anyone have suggestions for a possible cause of this type of error, or any troubleshooting that I could use to trace the problem?
