cyclonedx-win-x64 prefixing the file to be added with a "\", causing a FileNotFoundException.

[lweitzel01]

When running the cyclonedx-win-x64 CLI, it is prefixing the file to be added with a "\" and looking for it in the drive root and thus throwing the FileNotFoundException.

Adding file \jpetstore.war

Output below:

d:\jenkins\workspace\sample\Dependency-Track\JPetstore-deptrack-cli>cyclonedx-win-x64 add files --no-input --output-format xml --output-file bom.xml --exclude .git/** --base-path target

Processing base path d:\jenkins\workspace\sample\Dependency-Track\JPetstore-deptrack-cli\target Processing include pattern / Processing exclude pattern .git/** Adding file \jpetstore.war Unhandled exception: System.IO.FileNotFoundException: Could not find file 'd:\jpetstore.war'. File name: 'd:\jpetstore.war' at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String , FileMode , FileAccess , FileShare , FileOptions ) at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String , FileMode , FileAccess , FileShare , FileOptions , Int64 ) at System.IO.Strategies.OSFileStreamStrategy..ctor(String , FileMode , FileAccess , FileShare , FileOptions , Int64 ) at CycloneDX.Cli.Commands.Add.AddFilesCommand.GetSha1Hash(String filename) at CycloneDX.Cli.Commands.Add.AddFilesCommand.GetFileHashes(String filename) at CycloneDX.Cli.Commands.Add.AddFilesCommand.AddFiles(AddFilesCommandOptions options) at System.CommandLine.Invocation.CommandHandler.GetExitCodeAsync(Object value, InvocationContext context) at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context) at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseParseErrorReporting>b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass27_0.<<UseVersionOption>b__1>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseTypoCorrections>b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__24_0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseParseDirective>b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<<UseDebugDirective>b__0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext() --- End of stack trace from previous location --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

[daneluta]

Is there a workaround for this issue?

[Serraniel]

I am having the same issue

[Serraniel]

Is there a workaround for this issue?

In my case it helped to provide a trailing \ to the base path. I also submitted a change to automatically fix that.