Surfaced from a Qodo /improve on the Python port of PR #182 (daqifi/daqifi-python-core PR #102, importance 9). Same false-positive exists in the C# implementation.
Bug
`IsNonResultLine` (introduced in PR #182) uses a permissive prefix check:
```csharp
private static bool IsNonResultLine(string line)
{
var trimmed = line.TrimStart();
return trimmed.StartsWith("**ERROR", StringComparison.OrdinalIgnoreCase)
|| trimmed.StartsWith("ERROR", StringComparison.OrdinalIgnoreCase);
}
```
A legitimate file in an SD card listing whose name starts with `error` (e.g. `error_log_2026.csv`) matches `StartsWith("ERROR", OrdinalIgnoreCase)` and gets classified as a non-result error line by `ThrowIfSdCardListError`. If the entire listing is such files, `hasContentLine` is false, and the defensive fallback raises `SdCardOperationException` on what should have been a successful listing.
Fix (already shipped in Python port)
Tighten the prefix list to known firmware-emitted error shapes:
```csharp
private static bool IsNonResultLine(string line)
{
var trimmed = line.TrimStart();
return trimmed.StartsWith("**ERROR", StringComparison.OrdinalIgnoreCase)
|| trimmed.StartsWith("ERROR:", StringComparison.OrdinalIgnoreCase)
|| trimmed.StartsWith("ERROR !!", StringComparison.OrdinalIgnoreCase);
}
```
These cover every firmware error shape we know about:
- `**ERROR ...` — SCPI standard
- `ERROR: ...` — SCPI alt format with colon
- `Error !! ...` — firmware-specific status text
- `[Error:N]Failed to open directory ...` — already special-cased before reaching this helper
Filenames starting with `error` (no colon, no `!!`) won't match any of these.
Test (mirror in C#)
Add a test to `SdCardOperationsTests` that asserts a listing of files like `error_log_2026.csv` parses successfully without raising.
Refs
Surfaced from a Qodo /improve on the Python port of PR #182 (daqifi/daqifi-python-core PR #102, importance 9). Same false-positive exists in the C# implementation.
Bug
`IsNonResultLine` (introduced in PR #182) uses a permissive prefix check:
```csharp
private static bool IsNonResultLine(string line)
{
var trimmed = line.TrimStart();
return trimmed.StartsWith("**ERROR", StringComparison.OrdinalIgnoreCase)
|| trimmed.StartsWith("ERROR", StringComparison.OrdinalIgnoreCase);
}
```
A legitimate file in an SD card listing whose name starts with `error` (e.g. `error_log_2026.csv`) matches `StartsWith("ERROR", OrdinalIgnoreCase)` and gets classified as a non-result error line by `ThrowIfSdCardListError`. If the entire listing is such files, `hasContentLine` is false, and the defensive fallback raises `SdCardOperationException` on what should have been a successful listing.
Fix (already shipped in Python port)
Tighten the prefix list to known firmware-emitted error shapes:
```csharp
private static bool IsNonResultLine(string line)
{
var trimmed = line.TrimStart();
return trimmed.StartsWith("**ERROR", StringComparison.OrdinalIgnoreCase)
|| trimmed.StartsWith("ERROR:", StringComparison.OrdinalIgnoreCase)
|| trimmed.StartsWith("ERROR !!", StringComparison.OrdinalIgnoreCase);
}
```
These cover every firmware error shape we know about:
Filenames starting with `error` (no colon, no `!!`) won't match any of these.
Test (mirror in C#)
Add a test to `SdCardOperationsTests` that asserts a listing of files like `error_log_2026.csv` parses successfully without raising.
Refs