#3 Unable to specify full path in Windows

[pdaderko]

Hi,

I'm having a problem with xc3sprog... on Windows, I'm unable to specify a full path to a filename. For example, "xc3sprog -c ftdi ..\dir\led_test.bit" works, but "xc3sprog -c ftdi c:\dir\led_test.bit" throws an error ("Can't open datafile c: No such file or directory").

I looked at the source, and it appears the issue is that it strips out the ':' for things like: "aaaa.bb:action:0×10000|section:0×10000:rawhex:0×1000", but obviously on Windows, the ':' is an important part of the path.

I was planning to simply rebuild it to use ';' instead of ':' for that delimiter, though I'm having trouble compiling xc3sprog for Windows... and obviously that'd break existing usage. After some consideration, I decided maybe an official fix (or at least an official stance on how it should be fixed) would be more suitable.

I'm not sure what the best answer for this is... you could simply change the syntax, or detect that it's Windows and have different syntax, or maybe ignore a ':' if the full path is in quotes (or detect the "x:\" style). Or, I guess just leave it alone and say for Windows, you can't specify a drive letter (seems like a harsh limitation).

Any thoughts, and any chance of getting a fix?

Thanks,
Pat

[Uwe Bonnes]

Hello,

the problem in in the use of MINGW for windows compilation and the fopen() call in xc3sprog.c. At the moment I don't find a proper solution. Can you try with changing to the data directory first?

[Uwe Bonnes]

Probably using SetCurrentDirectory before fopen and restoring the directory afterwards will do. I try to find time the next days to implement and test.

[pdaderko]

Thanks for the help. I'm personally looking to use it with miniSProg ( https://github.com/scarabhardware/miniSProg ), which calls xc3sprog with the path to the file as an argument, but in general, it'd be nice to be able to specify a full path at the command line.

If SetCurrentDirectory doesn't solve the issue, one possible solution may be rather than using strchr to parse the string left-to-right... use strrchr to start from the right and parse in reverse. Then when you get to the filename, take it as a whole, including any ':' (since you know there won't be any remaining action, offset, etc).

Or, rather than looking for just ':' for the action, instead look for ":w", ":W", ":v", ":r", ":R". If the first ':' is part of the path, it should be followed by a '\' (or '/'), and would be skipped by those checks.

Let me know if there's anything I can do to help/test.

Thanks,
Pat

[Uwe Bonnes]

"pdaderko" == pdaderko pdaderko@users.sf.net writes:

pdaderko> Thanks for the help. I'm personally looking to use it with
pdaderko> miniSProg ( https:/ /github.com/scarabhardware/miniSProg ),
pdaderko> which calls xc3sprog with the path to the file as an argument,
pdaderko> but in general, it'd be nice to be able to specify a full path
pdaderko> at the command line.

pdaderko> If SetCurrentDirectory doesn't solve the issue, one possible
pdaderko> solution may be rather than using strchr to parse the string
pdaderko> left-to-right... use strrchr to start from the right and parse
pdaderko> in reverse. Then when you get to the filename, take it as a
pdaderko> whole, including any ':' (since you know there won't be any
pdaderko> remaining action, offset, etc).

pdaderko> Or, rather than looking for just ':' for the action, instead
pdaderko> look for ":w", ":W", ":v", ":r", ":R". If the first ':' is
pdaderko> part of the path, it should be followed by a '\' (or '/'), and
pdaderko> would be skipped by those checks.

pdaderko> Let me know if there's anything I can do to help/test.

I sent you a patch and a compiled test program yesterday. Feedback is
welcome.

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[pdaderko]

Great to hear, though I haven't received anything (did you send it via email?). Sending to my sourceforge user email should work, unless it gets blocked because it has an executable attached.

I'd be glad to test it and give you feedback ASAP.

Thanks,
Pat

[Uwe Bonnes]

"pdaderko" == pdaderko pdaderko@users.sf.net writes:

pdaderko> Great to hear, though I haven't received anything (did you
pdaderko> send it via email?). Sending to my sourceforge user email
pdaderko> should work, unless it gets blocked because it has an
pdaderko> executable attached.

pdaderko> I'd be glad to test it and give you feedback ASAP.

Of course, there was a windows executable (~700 kbytes) appended.

The proposed patch ist to skip over a colon at zero-base position '1' of the
file/action/format string in the Win32 case:

My experiments yesterday missled me. fopen is perfectly capable of handling
"c:xxxx" filenames.

Appended the proposed patch. As you didn't offer me an address to send the test
executable too, I suppose you succeeded in compiling.

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
commit a222f648cf33204f3fda081b22a7ce974b07bca6
Author: Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Date: Mon Apr 20 18:07:50 2015 +0200

xc3sprog: On Win32, allow a file spec like c:bla.bit:... .

diff --git a/xc3sprog.cpp b/xc3sprog.cpp
index e6eabca..ba5b625 100644
--- a/xc3sprog.cpp
+++ b/xc3sprog.cpp
@@ -435,7 +435,14 @@ FILE getFile_and_Attribute_from_name(
else
{
q = strchr(p,':');
-
+#if defined(WIN32)
+ if (p[1] == ':') {
+ / Assume we have a DOS path.
+ * Look for next colon or end-of-string.
+ */
+ q = strchr(p + 2, ':');
+ }
+#endif
if (q)
len = q-p;
else

[pdaderko]

As you didn't offer me an address to send the testexecutable
too, I suppose you succeeded in compiling.

No... unfortunately, I haven't been able to compile. I don't know why pdaderko at users.sourceforge.net didn't work, but if you could try sending to pdaderko at yahoo.com, I'd appreciate it.

Or, if you check it in, I can download it directly.

Thanks,
Pat