I have this weirdest bug. I'm extracting a list of files from a file,
using std.regex. Then, I try to open each of these, using
std.file.readText. This gives me this error:

std.file.FileException: In std\file.d(198), data file data: The
filename, directory name, or volume label syntax is incorrect.

Now, the funny thing is, the filename given (data) is wrong. The
filename extracted (and confirmed, by printing it) is data.ini. If I
hardcode the file name, no problem occurs.

So, printing the filename confirms that the regex works, and
hardcoding it confirms that readText works. Nothing else does
anything to the filename.

Does anyone have the slightest idea what might be wrong?

-- 
Simen

It could be that the string returned from the regex looks the same as the
hardcoded string but contains characters that don't show up when you print
it.
Does adding
assert(regexResult == expectedFilename);
throw?

"Simen kjaeraas" <simen.kjaras@gmail.com> wrote in message news:op.vewf53itvxi10f@biotronic-pc.lan...
>I have this weirdest bug. I'm extracting a list of files from a file,
> using std.regex. Then, I try to open each of these, using std.file.readText. This gives me this error:
>
> std.file.FileException: In std\file.d(198), data file data: The filename, directory name, or volume label syntax is incorrect.
>
> Now, the funny thing is, the filename given (data) is wrong. The
> filename extracted (and confirmed, by printing it) is data.ini. If I
> hardcode the file name, no problem occurs.
>
> So, printing the filename confirms that the regex works, and hardcoding it confirms that readText works. Nothing else does anything to the filename.
>
> Does anyone have the slightest idea what might be wrong?
>
> -- 
> Simen

Daniel Murphy <yebblies@nospamgmail.com> wrote:

> It could be that the string returned from the regex looks the same as the
> hardcoded string but contains characters that don't show up when you print
> it.
> Does adding
> assert(regexResult == expectedFilename);
> throw?

Not after I changed what was actually the problem - trailing spaces.
Still, the error I got gave absolutely no indication that that might be it.

-- 
Simen

On 26/06/2010 12:23, Simen kjaeraas wrote:
> Daniel Murphy <yebblies@nospamgmail.com> wrote:
>
>> It could be that the string returned from the regex looks the same as the
>> hardcoded string but contains characters that don't show up when you
>> print
>> it.
>> Does adding
>> assert(regexResult == expectedFilename);
>> throw?
>
> Not after I changed what was actually the problem - trailing spaces.
> Still, the error I got gave absolutely no indication that that might be it.
>
Yes it did. It told you exactly what was wrong.

The bit that says:

'The filename, directory name, or volume label syntax is incorrect.'

Its the error message from windows telling you that you got the file name wrong.

Trailing spaces are not allowed on windows, so it's not even tried to open a file, it's just told you that the file name syntax is wrong.

http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx

Though perhaps the formatting of the exception text should be changed a bit to make it clear which bit is the system error part.

If it bothers you enough, it's worth filing a bug report:

http://d.puremagic.com/issues/

Andrei and the rest of the guys are pretty quick at knocking off these issues.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0 <div0@users.sourceforge.net> wrote:

>> Not after I changed what was actually the problem - trailing spaces.
>> Still, the error I got gave absolutely no indication that that might be it.
>>
> Yes it did. It told you exactly what was wrong.

Awright, I agree I overstated things there. My point however, was that the
error message ate the file extension, making things harder to understand.

The exact symbol that was appended, was \r. The reason it seemed to eat
the extension was that the extension was the first thing on the new line,
and thus the carriage return overwrote everything from the beginning of
the line. I'm not sure if the error handler should take such symbols into
account.

-- 
Simen