The following works fine on Linux: (testfile: https://www.mikrocontroller.net/topic/257313#3991181) $ sigrok-cli -i testing.bin -I binary -o testing.sr -l 5 sr: libsigrok loglevel set to 5. sr: backend: Sanity-checking all drivers. sr: backend: Sanity-checking all input modules. sr: backend: Sanity-checking all output modules. sr: backend: Sanity-checking all transform modules. srd: libsigrokdecode loglevel set to 5. sr: input: Sending 9997 bytes to binary module. sr: input: Calling end() on binary module. sr: std: input/binary: Starting acquisition. sr: std: input/binary: Sending SR_DF_HEADER packet. sr: session: bus: Received SR_DF_HEADER packet. cli: Received SR_DF_HEADER. sr: session: bus: Received SR_DF_LOGIC packet (4096 bytes, unitsize = 1). cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1). sr: session: bus: Received SR_DF_LOGIC packet (4096 bytes, unitsize = 1). cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1). sr: session: bus: Received SR_DF_LOGIC packet (1805 bytes, unitsize = 1). cli: Received SR_DF_LOGIC (1805 bytes, unitsize = 1). sr: session: bus: Received SR_DF_END packet. cli: Received SR_DF_END. However, on Windows it fails like this: $ sigrok-cli -i c:\a\testing.bin -I binary -o c:\a\testing.sr -l 5 sr: libsigrok loglevel set to 5. sr: backend: Sanity-checking all drivers. sr: backend: Sanity-checking all input modules. sr: backend: Sanity-checking all output modules. sr: backend: Sanity-checking all transform modules. srd: libsigrokdecode loglevel set to 5. sr: input: Sending 9997 bytes to binary module. sr: input: Calling end() on binary module. sr: std: input/binary: Starting acquisition. sr: std: input/binary: Sending SR_DF_HEADER packet. sr: session: bus: Received SR_DF_HEADER packet. cli: Received SR_DF_HEADER. sr: session: bus: Received SR_DF_LOGIC packet (4096 bytes, unitsize = 1). cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1). sr: output/srzip: Error saving zipfile: Renaming temporary file failed: No such file or directory. sr: session: bus: Received SR_DF_LOGIC packet (4096 bytes, unitsize = 1). cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1). sr: output/srzip: Error saving zipfile: Renaming temporary file failed: No such file or directory. sr: session: bus: Received SR_DF_LOGIC packet (1805 bytes, unitsize = 1). cli: Received SR_DF_LOGIC (1805 bytes, unitsize = 1). sr: output/srzip: Error saving zipfile: Renaming temporary file failed: No such file or directory. sr: session: bus: Received SR_DF_END packet. cli: Received SR_DF_END. The testing.sr file is created but it is empty. The user has permissions to write to c:\a\, a simple "echo Foo > c:\a\foo.txt" works.
*** Bug 614 has been marked as a duplicate of this bug. ***
The same (well, a similar) problem also occurs for PulseView. This issue is partially related to mkstemp() and libzip. Older MinGW-w64 versions (3.x) didn't have a mkstemp() implementation. libzip detected this and used its own local implementation. Newer MinGW-w64 versions (4.x) do have a mkstemp() implementation, so libzip will use it. However, there seem to be issues in this case. Either libzip has incorrect assumptions about how mkstemp() works in detail, or the MinGW-w64 (4.0.2) implementation is buggy at the moment (or both?). Either way, as a workaround we're now forcing libzip to use its own mkstemp() implementation by building it like this: ./configure ac_cv_func_mkstemp=no ... This fixes the problem for PulseView. For sigrok-cli there's an additional issue that causes file saves to fail. When invoking "sigrok-cli ... -o c:\whatever\foo.sr" or such, this will internally be "converted" to the usage of the "srzip" output module with a "filename" parameter, basically resulting in something like this: ... -O srzip:filename=c:\whatever\foo.sr ... Since sigrok-cli separates options using the ":" character, this will yield a "filename" option that is set to "c" instead of "c:\whatever\foo.sr", which then leads to an incorrect save. A solution or workaround is being investigated.
If someone wants to look into the mkstemp() issue in order to find a proper fix, here are the relevant files: http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/misc/mkstemp.c#l30 http://hg.nih.at/libzip/file/a8e0fd752d49/lib/mkstemp.c
This is now fixed in 81b3ce374c3b6d48e5ed321ac7a871ce4248a0bb and 37875f7506143d97f44014260f07e6408ee8c9dc in libsigrok and 5d7604d168152ce4c419928b20f0ccfeb669ebba in sigrok-cli by no longer supplying the srzip output module with a "filename" option, but rather having a filename field in struct sr_output. This avoids the case of having filenames with ":" in them being supplied to sigrok-cli as option (of the srzip output module), which would result in incorrectly parsing the filename. Similarly, commit ad83f8faadeded7902eb3e25b608f45674b86fa0 in PulseView adapts for the above libsigrok change. Additionally, in sigrok-cli commit 5899178d2d92d12bb8bed7e6b874ea778b7329c2 fixes another issue related to srzip saving. Before the fix, attempting to save would yield a libzip error because libzip internally tries to rename a temporary ZIP file (e.g. foo.sr.ab7u4a) to the final name (e.g. foo.sr). However, on Windows file renaming is not possible if the file has already been opened by any process, which sigrok-cli was doing. The fix is easy though, in the case of srzip we just don't open the (e.g. foo.sr) file in sigrok-cli. That's not required anyway since the srzip output module does all the file writing and opening/closing/renaming, and fixes this problem on Windows at the same time.