[tc10.51rc2] error handling of LOADLIST

[AntonyD]

They are invalid and are ignored.

very silent? why not inform me - as USER - about such problematic cases in MY list?
Or I misunderstand current explanations and behavior?
I don't see "not found" or "wrong instance"...

[white]

Well, Total Commander just passes the paths to FindFirstFile, and the help for that Windows function doesn't mention wildcards in the path part:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilea

It says wildcards can be used in the last part (after last backslash), so not in the paths.

[ghisler(Author)]

very silent? why not inform me - as USER - about such problematic cases in MY list?

TC reports an error if Windows returns an error searching for a path, which doesn't seem to happen here. It just returns an empty result.

[AntonyD]

2ghisler(Author)

It just returns an empty result.

Sooooo, now, after these conversations you know that Windows Docs|API is not very useful and logical sometimes happen
For example in this current case we must validate users' input BEFORE sending it to FindFirstFile.
And for all forbidden instances (like wildcards chars in 'path' segment) report to USER, that this, this and this lines are wrong - and will not be used.

[white]

For example in this current case we must validate users' input BEFORE sending it to FindFirstFile.
And for all forbidden instances (like wildcards chars in 'path' segment) report to USER, that this, this and this lines are wrong - and will not be used.

Indeed, work around the Windows peculiarities and bugs. Especially that \\?\c:\thisfiledoesnotexist.txt doesn't generate a file not found error is a Windows bug in my opinion. Because support for \\?\ is mentioned in the API docs.

[ghisler(Author)]

Wildcards in the path should now cause an error. I have just released RC4, please test it!

Currently I'm not checking for prefix \\?\

[white]

Wildcards in the path should now cause an error. I have just released RC4, please test it!

Confirmed fixed.

Currently I'm not checking for prefix \\?\

Indeed, confirmed not fixed

---

Make sure a file named "test" exists and use LOADLIST to load a file with the following line:

Code: Select all

t<est

TC says there are 2 errors instead of 1.

---

Now add "|test" at the top:

Code: Select all

|test
t<est

TC says there is 1 error and 1 file found. The displayed file is not accessible.

---

Now add file names that don't exist until 9 (or more) lines are in the list file:

Code: Select all

|test
t<est
3
4
5
6
7
8
9

Now, no files are found and 9 errors.

[ghisler(Author)]

t<est triggers a double error, first because it contains the forbidden character "<", and second because noting was found. I will suppress the second error.

The reason why the search for \\?\c:\thisfiledoesnotexist.txt doesn't generate a file not found error is that the ? in the path makes the function wrongly assume that it has wildcards.

Currently wildcard searches do not give an error when nothing is found. Example:
1. Search for
*.txt
but there is no text file in the base directory -> no error, because the user didn't look for a specific file
2. Search for test.txt
but the file test.txt doesn't exist -> error, missing file
3. Search for
c:\bad path\*.txt
-> error when "bad path" doesn't exist because the user explicitly looked for it.

What do you think? Should it show an error when *.txt return zero results? Or would this annoy people who look for multiple file types like
*.docx
*.xlsx
*.txt
and be content if just one of them returned a result?

[white]

The reason why the search for \\?\c:\thisfiledoesnotexist.txt doesn't generate a file not found error is that the ? in the path makes the function wrongly assume that it has wildcards.

That's what I meant with:

Entries with wildcard characters in the path never throw a not found error.
c:\test*123\test1.txt
\\?\c:\test1.txt:Zone.Identifier

A solution for \\?\c:\thisfiledoesnotexist.txt could be, if FindFirstFile doesn't find any files, check if passed filename started with \\?\ and doesn't contain any other wildcard characters. If this is the case, show a file not found error.

What do you think? Should it show an error when *.txt return zero results? Or would this annoy people who look for multiple file types like
*.docx
*.xlsx
*.txt
and be content if just one of them returned a result?

In my opinion, no error when there are zero results when using wildcards. If in the future people want an error in this case, they can make a suggestion. Perhaps then a command modifier can be made, or another solution.

[ghisler(Author)]

A solution for \\?\c:\thisfiledoesnotexist.txt could be, if FindFirstFile doesn't find any files, check if passed filename started with \\?\ and doesn't contain any other wildcard characters.

No, I will just skip the \\?\ at the beginning of the path when looking for wildcards.

In my opinion, no error when there are zero results when using wildcards.

OK, then I will keep it as it is for lines with actual wildcards.

[white]

Leading and trailing spaces are supported. Which is nice because file lists created by TC will also contain these if files have leading or trailing spaces.

However, it can be confusing if people edit the list file and accidentally add spaces ate the end. Perhaps if a filename is displayed as not found and ends with a space, add a backslash \ at the end?

These both find the file "c:\test\trailing space ":

Code: Select all

c:\test\trailing space 
c:\test\trailing space \

But these don't:

Code: Select all

\\?\c:\test\trailing space 
\\?\c:\test\trailing space \

These find the file "c:\test\trspacefile " if current drive is c:\test, but not if current drive is \\?\c:\test (probably same cause as previous case)

Code: Select all

trspacefile 
trspacefile \

Quotes are not supported, but messes up the error

Code: Select all

"test1.txt"                   (error is OK: "test1.txt")
"c:\test\test1.txt"           (error is: test1.txt")
"\\?\c:\test\test1.txt"       (error is: c:\test\"\\?\c:\test\test1.txt")

Perhaps it is easiest to also support quotes around the entire name and strip them when you read the file. In that case also trim leading and trailing spaces outside the quoted filename.

Another case:

Code: Select all

 \\?\c:\test\test1.txt        (error is: c:\test\ \\?\c:\test\test1.txt")

[ghisler(Author)]

Sorry, I will not change this at this time. Maybe in a later version.

[Horst.Epp]

If you make some changes in the future,
may I repeat my suggestion to add a LOADLIST function as a command line switch.
This will make a lot of scripting easier.

[white]

31.08.22 Fixed: LOADLIST didn't show error for non existing files with paths with prefix \\?\, e.g. \\?\c:\nofilehere.txt (32/64)
31.08.22 Fixed: LOADLIST didn't work when called again in a list previously loaded with LOADLIST when not using folder tabs (32/64)
30.08.22 Fixed: LOADLIST didn't correctly handle paths with prefix \\?\, treated them as wildcards (32/64)

Tested OK using TC10.51.

[ghisler(Author)]

Great, thanks for the confirmation!