[tc10.51rc2] error handling of LOADLIST

[white]

Moderator message from: white » 2022-09-02, 07:23 UTC

Moved back to Bugs forum. (Was moved to Fixed bugs by Stefan2)

Thread still contains issues to be fixed.

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

[ghisler(Author)]

I will move this to "will not be changed" because I don't see a way to fix this.
1. A search for "c:\test\trailing space " or "c:\test\trailing space \" (without the quotes) with FindFirstFile returns the right file details
2. A search for "\\?\c:\test\trailing space " or "\\?\c:\test\trailing space \" (without the quotes) with FindFirstFile returns error 53, ERROR_BAD_NETPATH

So it seems that FindFirstFile doesn't work when the file has both the \\?\ prefix and a trailing space.

[AntonyD]

I'm sorry, but the documentation for the FindFirstFile function used says that the parameter with the file name to search:
"should not be NULL, an invalid string (for example, an empty string or a string that is missing the terminating null character), or end in a trailing backslash (\)."
Therefore, such lines must be corrected immediately on their own or issue a warning to the user that there are search instances in the list that do not have a clear indication of which object should be searched - either this is a file or this is an end folder, after which you just forgot to add the name of the file you are looking for!

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
"Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp"."

[white]

I will move this to "will not be changed" because I don't see a way to fix this.
1. A search for "c:\test\trailing space " or "c:\test\trailing space \" (without the quotes) with FindFirstFile returns the right file details
2. A search for "\\?\c:\test\trailing space " or "\\?\c:\test\trailing space \" (without the quotes) with FindFirstFile returns error 53, ERROR_BAD_NETPATH

So it seems that FindFirstFile doesn't work when the file has both the \\?\ prefix and a trailing space.

Weird, but can't be helped.

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")

What about the current dir getting prepended to the filename in the error?

[Fla$her]

2ghisler(Author)
Here they ask about indications of errors. And what about the request to get rid of the error window, given that their number in the window is limited and essentially useless?

[white]

I will move this to "will not be changed" because I don't see a way to fix this.
1. A search for "c:\test\trailing space " or "c:\test\trailing space \" (without the quotes) with FindFirstFile returns the right file details
2. A search for "\\?\c:\test\trailing space " or "\\?\c:\test\trailing space \" (without the quotes) with FindFirstFile returns error 53, ERROR_BAD_NETPATH

So it seems that FindFirstFile doesn't work when the file has both the \\?\ prefix and a trailing space.

Weird, but can't be helped.

Found a way

One nifty trick in Search (Alt+F7) when using a list file (@c:\subdir\list.txt) is to use the following notation in the list file:
c:\test\*"filename"

This searches for exact match with the filename, but because of the wildcard it also searches for the filename in subdirectories.
It seems this notation also works for LOADLIST and surprise, surprise, it even works with \\?\. And with this notation, there is no space at the end so this works:

Code: Select all

\\?\c:\test\*"trailing space "

So in case of the error 53 (ERROR_BAD_NETPATH), you could do this:

• check if the parameter started with \\?\ and ended with a space " " or space backslash " \". If so continue.
• remove the backslash at the end if present (or it will fail)
• replace the last part (part without the path) with *"lastpart"
• check again if it can be found

BTW, this notation doesn't hinder any wildcard use within the quotes. That works as usual.

[andry81]

Just for instance: https://stackoverflow.com/questions/2563316/findfirstfileex-wildcard-characters

[white]

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.

05.09.22 Fixed: LOADLIST command: Support double quotes around names in the list, e.g. when it contains spaces (32/64)

Tested using TC10.52rc1.

Leading and trailing spaces outside the quoted filename are not ignored.
In case of spaces behind a quoted filename: quotes do not end up in the error. It looks as though the quotes are removed even when there are trailing spaces behind the quote, but the trailing spaces are not removed.

Furthermore, a loose trailing double quote will be ignored when looking for the file and ends up in the results, which can then not be accessed. For example:

Code: Select all

c:\test\test1.txt"