LOADLIST does not load records about files on partition E:\

[Gral]

2 AntonyD
First of all - try with fresh INI file!

[ghisler(Author)]

I also tried this with a removable disk (USB flash drive) and the file list was loaded including the file on the flash drive.

Maybe something else is wrong, e.g. the file name contains a Cyrillic character which looks like a Latin character, e.g. these two lines look the same, but the first are all Cyrillic characters and the second are all Latin:
ЅАВЕМНОРСТ
SABEMHOPCT
If you have the Cyrillic character(s) in the file name, but the Latin one(s) in the list, the name will not be found.

[white]

From what I understand, he already tried normal characters. Notice that he reported that he get's an error when he deliberately enters a name that does not exist. For any existing file in any folder on his E: drive, he doesn't get an error but the file is not shown. The contents of the list file doesn't matter, it does not matter if files on other drives are in there as well. That was just an example to make clear that it is drive specific.

It is unclear whether he tried with a clean ini yet.

[AntonyD]

E:\ is a regular HDD drive

I already tried with empty.ini - because initially I started to look into this issue in another topic, which I mentioned above.

I already above provided info about the case when I forcibly used an additional removable disk F:\ - and all was fine.

Again - there is no something special with filenames on this partition. And in my tests I've used only English names of such files.
And again - IF there was any problem with the file name, I would have received a special dialog with notification from Total.
But I didn't.... And I've checked this behavior separately - it occurs if I actually use the wrong file name in this file-list.
My current case is not this case.

2white
You are the best - you understood everything correctly!


2ghisler(Author)
Please - just let's start to add a good comprehensive logging system for the internal behavior of the program's code,
designed for various use cases.

[ghisler(Author)]

2AntonyD
Sorry, I can't add a log entry for every single line in code, especially for code where no one else has this problem.

[AntonyD]

I'm not hinting at the need to log every single line. Let's not exaggerate. I'm hinting at the need for extended logging in general.
Even at the coarse-grained logging level, the amount of information currently recorded in the available log is too small.
It's simply criminally insufficient.

And here's the current version of the problem - it will be impossible to resolve - without comparing the log of the program's behavior between
me, you, or someone else. Because based on the description of this problem none of the potential incorrect file writing handling scenarios apply.
It doesn't reproduce on your side, and I believe it doesn't reproduce for others either. BUT it reproduces for me!

And clearly for a very strange reason.
Maybe even for a very trivial reason that I would never have paid attention to. But this reason is just very out of sight available,
we might have just gotten used to it being on, and I suddenly turned it off.
BUT definitely without a log - at which stage the DISABILITY in the output to the screen is made - we will not find it.

[AntonyD]

I was able to test this command on another computer with available partitions C/D/E/F/G/H/I/J. J = is removable, others - HDD+SDD.
The F and G partitions do not display their files... belons to one physical HDD. JUST LIKE as and E:\ partition. But it is able to show files.

[ghisler(Author)]

Could you check with "process monitor" (not "process explorer") from https://www.sysinternals.com please? Maybe you can see whether there is some kind of read error on the affected drives.

[AntonyD]

During the testing of this bug, I came across another one, please read its description carefully https://www.ghisler.ch/board/viewtopic.php?t=85862

[AntonyD]

Could you check with "process monitor" (not "process explorer") from https://www.sysinternals.com please? Maybe you can see whether there is some kind of read error on the affected drives.

Yes, I did it. And I made sure that Total checks all records from the file-list for actual existence.
And I see that Total received confirmation of such existence. No errors.
And then I see how the data filling process went in the output on the file panel in a tab and it's clearly visible
that ONLY those files that are NOT on the F:\ + G:\ partitions went into this processing.
So these files from these drives were not even attempted to be processed. But why?
There is no answer in this utility. A detailed log is needed. No matter how you think about it...

[ghisler(Author)]

Maybe you have files on drive E: on the ignore list?
Configuration - Options - Ignore list
or
allowed=drives
in wincmd.ini? The latter can also be set via registry.

[petermad]

2AntonyD

Have you checked that thre are no trailing spaces in the list file. What is the encoding of your list file? Could you maybe put your list file up for download, so others can test it?

[AntonyD]

2ghisler(Author)
Ignore list is empty
'allowed' registry key was not found (And the question - where is this option in the settings dialog? Just do not say that it is not there.
Because I checked each tab - I have NOT found active fields anywhere that would have been related to the mentioned letters
of the disk partitions).

2petermad
Why, after my explanations and answers above, do you still have questions about the file file?
1) no trailing spaces. And if they even were, then I would immediately receive a dlg with an error about finding a file,
But I have already announced three or four times that I have no errors during this process...
2) I've check ALL possible encodings. ANSI, UTF-8, UTF-16. w and w/o BOM. But even if I ever had a problem with the encoding
of the file, then it would be reflected in that Not a single file from this list would load or display!
Just because coding breaks Absolutely all the file's content once and for all. But I can see SOME file records)))))))
3) There is no sense in the text of the file-list itself, because you can choose any file on each partition of your disks as a record
to simply check this behavior. The specific contents are not important here. I indicated above that in Process Monitor I was able
to clearly observe both phases of the command processing (at least two - the most important): processing each entry from the file
and the attributes of those file were checked. And all checks are passed OK - and each check gives positive results.
Those All file entries exist and they are valid and Total can use them.
But in the second part of the processing - some part of the file records was simply absent. For some inner reason of the Total's code.

And without logs, we can still guess forever. I don’t understand why this most important component of any such painstaking development
of a product of a similar level of complexity might suddenly be practically absent. In the form that it is represented is almost zero.
Total cannot exist without a sophisticated system for logging internal code processing processes.

[sa16]

2AntonyD
And with Alt+F7, the files under discussion (from disk E) are displayed in the search results?

[AntonyD]

yep