I migrated from TFS 2015 to TFS 2017 and after the upgrade I moved the distribution of the artifacts from the build to a release-step (after the build-step).
In the release-step I delete all content of the output-folder (on a network share) and copy the artifacts and some needed setups (laying on a network share) to the output folder.
Most of the time the copy process works fine but once a while (once every 4-5 tries) the copying of the needed setups fails with a bad-file-descriptor:
2018-12-03T16:10:35.6151925Z ##[debug]testing directory '\\My\Fancy\Network\Share\Development\CD\ExpressionBlend'
2018-12-03T16:10:35.6164686Z ##[debug]task result: Failed
2018-12-03T16:10:35.6210378Z ##[error]Error: EBADF: bad file descriptor, stat '\\My\Fancy\Network\Share\Development\CD\ExpressionBlend'
2018-12-03T16:10:35.6218500Z ##[debug]Processed: ##vso[task.issue type=error;]Error: EBADF: bad file descriptor, stat '\\My\Fancy\Network\Share\Development\CD\ExpressionBlend'
2018-12-03T16:10:35.6235282Z ##[debug]Processed: ##vso[task.complete result=Failed;]Error: EBADF: bad file descriptor, stat '\\My\Fancy\Network\Share\Development\CD\ExpressionBlend'
I'm thankful for every hint, as I don't have any idea where to start...
Related
I'm running a job with Pentaho Data Integration 8.1, I retrieve a file frop ftp, work on it and move it to a folder.
I tried, as I did many other times with no problems, to use 'Move Files', but I get this error:
Move Files - ERROR (version 8.1.0.0-365, build 8.1.0.0-365 from 2018-04-30 09.42.24 by buildguy) : There was an error moving file [file:///C:.../file.csv] to [file:///C:.../file.csv] : [Could not rename "file:///C:.../file.csv" to "file:///C:.../file.csv".
I checked permissions on the file and on the destination folder, everything's fine.
I tried to use "Process result filenames" step with no success.
I tried to rename or delete the file instead of moving it, same error.
I tried to move this job into a new parent one, with "Move Files" step in it, same error again.
I also tried not including the filename to result prior to the Move Files step: nothing.
Then I wrote a simple shell script:
cd\
cd C:\...\working_directory
move "filename with spaces.csv" /destination_folder
and I get this (I translated it from italian):
ERROR (version 8.1.0.0-365, build 8.1.0.0-365 from 2018-04-30 09.42.24 by buildguy) : (stderr) No access to the file. The file Š is used in another process.
The file isn't used in any other process, I can move it manually without the spoon process running, so I think the ftp step, or the transformation one I use to work on the file (simple 'CSV Input' and ETL) somehow keep the file open.
Any idea as to how to "unlock" the file, so that it can be moved?
I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.
I've been working on a project for some time now and now I want to use Visual Studio Team Services for it. Locally, the building in Visual Studio doesn't give an error and the application works as intended.
I've checked in this working code to VSTS so it's in the repo and good to go.
Now I want to build it. I created a new Build definition with nothing changed. When I run the build it fails. I tried editing the build definition but with my 0 experience with this I only screw up more and create more errors.
My problem: Apparently, it wants to find C:\a\1\s But I have no idea why and how it came up with that path.
What do I have to change in the build definition? I'm new to this so I don't know what all the settings do and where the files are that it needs.
I tried adding the .sln file from the project folder to the build definition (as shown in the 2nd image) but it still want to find that weird path.
So here are the build definitions, steps that go wrong and the errors in the logs.
NuGet restore ***.sln
2016-03-07T10:28:15.8302718Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18
2016-03-07T10:28:15.9337363Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18\NuGetInstaller.ps1
2016-03-07T10:28:16.5636975Z ##[error]Could not find a part of the path 'C:\a\1\s'.
2016-03-07T10:28:16.5876990Z ##[error]No solution was found using search pattern 'C:\a\1\s\**\*.sln'.
Copy Files to: $(build.artifactstagingdirectory)
2016-03-07T10:28:16.6827013Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11
2016-03-07T10:28:17.1800860Z ##[debug]check path : C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1810857Z ##[debug]set resource file to: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1810857Z ##[debug]system.culture=en-US
2016-03-07T10:28:17.1820859Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1820859Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:28:17.1820859Z ##[debug]Contents=**\bin\release\**
2016-03-07T10:28:17.1830859Z ##[debug]SourceFolder=C:\a\1\s
2016-03-07T10:28:17.1830859Z ##[debug]check path : C:\a\1\s
2016-03-07T10:28:17.1840858Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\lib.json
2016-03-07T10:28:17.1840858Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:28:17.1850860Z Not found SourceFolder: C:\a\1\s
2016-03-07T10:28:17.1860857Z ##[debug]task result: Failed
NuGet restore $/Test project/QRM/QRM.sln
2016-03-07T10:47:46.0629142Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18
2016-03-07T10:47:46.1969152Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18\NuGetInstaller.ps1
2016-03-07T10:47:46.8519190Z ##[error]Cannot find path 'C:\a\1\s\QRM\QRM.sln' because it does not exist.
2016-03-07T10:47:46.8639180Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\agent\worker\tools\NuGet.exe restore "C:\a\1\s\QRM\QRM.sln" -NonInteractive
2016-03-07T10:47:48.8829320Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-03-07T10:47:48.8999324Z ##[error]Could not find a part of the path 'C:\a\1\s\QRM\QRM.sln'.
2016-03-07T10:47:48.9249320Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
Copy Files to: $(build.artifactstagingdirectory)
2016-03-07T10:47:49.0239330Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11
2016-03-07T10:47:49.6659427Z ##[debug]check path : C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6779370Z Not found SourceFolder: C:\a\1\s
2016-03-07T10:47:49.6789372Z ##[debug]set resource file to: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6799369Z ##[debug]system.culture=en-US
2016-03-07T10:47:49.6799369Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6809368Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:47:49.6809368Z ##[debug]Contents=**\bin\release\**
2016-03-07T10:47:49.6809368Z ##[debug]SourceFolder=C:\a\1\s
2016-03-07T10:47:49.6819369Z ##[debug]check path : C:\a\1\s
2016-03-07T10:47:49.6819369Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\lib.json
2016-03-07T10:47:49.6829365Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:47:49.6829365Z ##[debug]task result: Failed
Edit
The build definition's repository tab:
The repository structure:
According to the logs you provided:
2016-03-07T15:00:44.4590685Z Done syncing repository Test project to version 3 (workspace version -1)
This issue may caused by the access permission of your build account. Please check and make sure the account that the build agent use has the permission to access to your code repository.
Same issues for your reference:
TFS 2105 build issue
TFS 2015 Build Agent failing syncing the repository
When you queued a new build, did you enter a Source Version to get? I see a Version 3 coming by in the logs, but no files are actually transferred. If you want to fetch a specific changeset, you need to enter C3 instead of 3. But I'd recommend to just leave the box empty.
I followed all the instruction mentioned in https://github.com/cisco/openh264 but I am unable to get through. The information is cited in link but its quite confusing.
Alternative Way:
You can build Openh264 using visual studio in windows. Here are the steps..
i) Download OpenH264 source code provided by cisco (that already you
mentioned https://github.com/cisco/openh264).
ii) Now you will find two visual studio compatible projects in
directory /OpenH264/codec/build/win32/dec and
/OpenH264/codec/build/win32/enc.
iii) You will need to download NASM software from http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/
iv) Install NASM software on the directory C:\NASM or wherever you like.
v) Then Add NASM executable path to all these visual studio projects.
vi) Then You can either select static or dynamic library in general
options.
vi) If you are able to perform all these operations successfully, you will have 5 different .lib or .dll files named welsdcore, welsdecplus, welsecore, welsencplus, welsvp and those
are usable in any visual studio projects.
Now if you want to get openh264 features, just add all these libraries to your project and enjoy.
Hope it will help you.. :)
I also had some difficulty building openh264 on Windows using the recommended mingw approach.
In my case make crashed for all configurations I tried:
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug clean"
bash -c "make OS=msvc ARCH=x86_64 USE_ASM=No BUILDTYPE=Debug"
0 [main] make 3888 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
564 [main] make 3888 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
0 [main] make 5448 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
561 [main] make 5448 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
copying dll files to destination folder...
FullDestDir is E:\projects\openh264\bin\x64\Debug
current dir is:
E:\projects\openh264
DestDir is bin/x64/Debug
cp: cannot stat `openh264.dll': No such file or directory
cp: cannot stat `openh264.lib': No such file or directory
cp: cannot stat `openh264.pdb': No such file or directory
cp: cannot stat `codec_unittest.exe': No such file or directory
cp: cannot stat `h264enc.exe': No such file or directory
cp: cannot stat `h264dec.exe': No such file or directory
BuildDebugFlag =1
BuildReleaseFlag =0
BuildDebugInfo ="build debug--failed"
BuildReleaseInfo =NULL
aBuildFlagList is 1 0
ReturnCode is 1
I resorted to converting the existing solution/projects (VS2008) to VS2013 and linking/building with the created .lib files.
You can find the solutions in {openh264_dir}\codec\build\win32\enc and {openh264_dir}\codec\build\win32\dec.
Building the solution will create .libs and .dlls in {openh264_dir}\bin\Win32\Release
To link to the lib, you need to link to welsenc.lib.
When running, you need to have both the welsenc.dll and welsvp.dll in your application directory. So far it seems to have worked fine for my usage.
I'm assuming that building the decoder will be similar.
I have a rather standard setup with a development stream (devStream) that delivers to and rebases from an integration stream (intStream).
I have a file in my development view (devView) that I can checkout, modify, and checkin normally.
However, when I attempt to deliver (and later rebase) however I get an error that baffles me... (especially as I have been delivering and rebasing for the past 6 months) It may be worth noting that we recently upgraded from Rhapsody 8.0.2 to 8.0.4 (and correspondingly upgraded the diffmerge tool that clearcase's map file points to for rhapsody files), however given when the errors are arising I can't see how this could be at fault.
Since the graphical mode can be hard to get enough debug info from I captured the results of some command line runs.
Here's the (annonymized) result for
starting a rebase
cleartool> rebase -recommended
*SNIP*
Creating integration activity...
Setting integration activity...
Merging files...
Checked out "C:\CCVs\myDevView\shortenedPath\theFile.sbs" from version "\main\intStream\devStream\9".
Attached activity:
activity:NSSLB00001350#\projects "rebase devStream on 20131120.195128."
Needs Merge "C:\CCVs\myDevView\shortenedPath\theFile.sbs" [to \main\intStream\devStream\CHECKEDOUT from \main\intStream\9 base \main\intStream\8]
cleartool: Error: Unable to access "C:\CCVs\myDevView\shortenedPath\theFile.sbs": No such file or directory.
cleartool: Error: An error occurred while merging file elements in the target view.
cleartool: Error: Unable to perform merge.
cleartool: Error: Unable to perform integration.
cleartool: Error: Unable to rebase stream "devStream".
attempting to resume the rebase
cleartool> rebase -resume
Rebase in progress on stream "devStream".
Started by "XXXXX" at 11/20/2013 7:51:28 PM.
Merging files...
cleartool: Error: Unable to access "C:\CCVs\myDevView\shortenedPath\theFile.sbs": No such file or directory.
cleartool: Error: Some files are already checked out to a non-integration activity in the target view.
cleartool: Error: Unable to perform merge.
cleartool: Error: Unable to perform integration.
cleartool: Error: Some files are already checked out to a non-integration activity in the target view.
cleartool: Error: Unable to resume rebase.
listing the information associated with the thusly created integration rebase activity
cleartool> lsactivity -long NSSLB00001350
activity "NSSLB00001350"
2013-11-20T19:52:00-06:00 by XXXXXX
"Integration activity created by rebase on 11/20/2013 7:51:28 PM.
"
owner: XXXXX
group: XXXXX
stream: devStream#\projects
current view: myDevView
title: rebase devStream on 20131120.195128.
change set versions:
C:\CCVs\myDevView\shortenedPath\theFile.sbs##\main\intStream\devStream\CHECKEDOUT.94426
clearquest record id: NSSLB00001350
clearquest record State: Active
cleartool>
listing checkouts for anyone, on any stream, anywhere in this portion of the directory structure
cleartool> lsco -r
--11-20T19:51 XXXXX checkout version ".\shortenedPath\theFile.sbs" from \main\intStream\devStream\9 (reserved)
Attached activity:
activity:NSSLB00001350#\projects "rebase devStream on 20131120.195128."
At this point I'm confused about how to proceed. Googling isn't bringing up anything that seems relevant (or maybe my google skills are weak).
It's also worth pointing out that my clearcase skills are entirely self-taught on an as-needed basis... so I'm sure I've got holes in my knowledge. Meaining even if something seems like it would have been obvious to do, please point it out; I may be unaware.
Requested Info
With no rebase being attempted
C:\CCVs\myDevView\shortenedPath>cleartool ls
theFile.sbs##\main\intStream\devStream\9 Rule: ...\devStream\LATEST
theFile.sbs.merge
theFile.sbs.merge.1
theFile.sbs.merge.2
theFile.sbs.merge.3
theFile.sbs.merge.4
*snip (other files)*
In middle of failed rebase
theFile.sbs##\main\intStream\devStream\CHECKEDOUT from \main\intStream\devStream\9 [not loaded, checkedout but removed]
*snip*
theFile.sbs.merge.5
So... the rebase is doing something odd to the file; but why does it dissapear when doing a rebase/deliver and not when doing a normal checkout?
To debug this, you must go to the command line, in a shell, and go to the parent folder of the missing file:
cd /path/to/target/view/path/to/parent/folder
# in your case
cd C:\CCVs\myDevView\shortenedPath\
cleartool ls
cleartool lsvtree -graph .
The status of the file returned by the cleartool ls can give you a clue as to what is going on.
For instance "checkout but removed" would means the mergetool tried to access/open that file, but somehow it was deleted: that happens when said file is taken by a process, and cannot be completely checked out.
The lsvtree can also give you clues regarding the parent folder (to see if it was merged or not).
Another approach is to cancel that rebase, and try it again in a dynamic view instead of a snapshot view, in order to avoid any side-effect with a snapshot view not correctly updated.
The OP Khanmots concludes in the comments:
I undid the rebase (to get a copy of the file) and started it again.
When it bombed out I copied the file back in then hit to restart the rebase. Deleted it again.
I then replaced the file while leaving the prompt to start the diffmerge tool open, this allowed diffmerge to actually launch... but when I tell the diffmerge to save (after resolving differences) it deletes the file and creates another .merge.# file.
At this point it's looking like it's a diffmerge issue and not a clearcase issue.