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

[petermad]

2AntonyD

Hmm I tried with these files on my system
a:\xyz.txt
c:\xyz.txt
d:\xyz.txt
e:\xyz.txt
f:\xyz.txt
g:\xyz.txt
m:\xyz.txt
y:\xyz.txt

Drive a: is a SD memorycard (exfat)
Drive c: is the NTFS system drive (SATA hdd)
Drive d: is a NTFS partition
Drive e: is a FAT32 partition
Drive f: is a FAT32 partition
Drive g: is a NTFS partition
Drive m: is a network share of a laptop's drive C:
Drive y: is a WebDav drive connected to my phone via the WIFI transfer pluigin

So sorry, no matter how hard I try I cannot reproduce your problem.

[AntonyD]

2petermad
That's all right)) that's exactly what I thought and think now. A lot of people won't reproduce my bug.
And it is likely that the reason will be some very trivial one, but unfortunately, we will not find it just by guesswork.
We need to look for it more technically.

[Fla$her]

2AntonyD
1. What are the rights of the drive and the upper folders? If you use takeown at the root, will nothing change?
2. Does the list appear in the panel after LOADSEARCH==<stored search> with @Path\to\list.txt in the options?
3. If you change the drive letter (diskmgmt.msc /s), for example, to X:, and then replace E: with X: in the file list, will something change?

[ghisler(Author)]

Some more things you could test:
4. Does it work when you put files from subdirectories of these drives in the list, e.g. e:\test\somefile.ext instead of e:\somefile.ext ?
5. When using
subst x: e:\
Can you then add files on drive x: via LOADLIST ?

[white]

4. Does it work when you put files from subdirectories of these drives in the list, e.g. e:\test\somefile.ext instead of e:\somefile.ext ?

He started out with a file in a subdirectory and only later tried the root. And he confirmed in this thread that location of the file on the drive does not matter.

[sa16]

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....

If you use the LOADLIST command from the command line (%COMMANDER_EXE% /O /T /S LOADLIST:%COMMANDER_PATH%\EV-Results\EV-Results.txt)
then there will be no notification...

[AntonyD]

1) Full right. It's regular HDD. Nothing special. I did no play with security attribs at all.
When WINDOWS was initially installed - it took/set all expected and needed permissions on the go.
I was not required to change or re-set anything for any entire disk, or for any particular partition.
I am not experiencing any problems accessing any part of the partitions or disks. All files and folders are available.
Including when just doing the search in Total! That is! If I set the search for this file directly and find it I can "Feed to listbox".
And then access it by any means! Including the Total's tools. So the file/partition/disk does not have any restrictions on access.
2) pls provide a more detailed info HOW to use this command. LOADSEARCH==winnt (where 'winnt' - is a name of saved search
because my problems in a past began with e:\MinGW\include\winnt.h file) does not work.
Phrase c @Path\to\list.txt in the options I can translate as "with @Path\to\list.txt" in the options - but which
options are mentioned here? You mean I must create a button? From a Command line - the call will not work?
3) and 5) I will take the liberty of combining these points - since the result is the same - files from the new disk/letter do not appear
in the final output on the file panel of the "Search result:" tab.
4) as white already mentioned - yes - I already wrote about this possibility and so I tested this. All is the same. NO output.

2[sa16] - yes. My attempts already show this "feature" for me so all my last test were performed from Command line later.
Where I for sure is getting appropriate dialog with warning in case when wrong file-record will be presented in an input file-list.

P.S.
By the way, while testing, a suggestion came up that in the dialog for warning output about "a certain file not found" in the list,
it is necessary to indicate its FULL name - exactly as it is listed in a file! Because it is very strange to specify JUST the name, while
the file may exist as copies in different partitions/disks - and therefore it may not exist in only ONE place (there can be access issues)
and the goal = to specify THIS particular file in this warning dialog = this can only be done by indicating its FULL PATH - as it is listed
in the input file-list. Otherwise, it ends up being gibberish - another guessing game is starting.

[AntonyD]

2ghisler(Author)
If you are not ready to send me a special version with extended logs to pinpoint the issue that prevents files from being output to the panel, then I am basically ready to drop this topic into the "will not be changed" section. Because I see that this is a hard-to-reproduce bug, and I am basically the only one experiencing it, there is no sense in slowing down the development process. I only needed this functionality to check one useful behavior, but since it's not working, we'll just do everything the old-fashioned way. Nothing terrible will happen.

[sa16]

Where I for sure is getting appropriate dialog with warning in case when wrong file-record will be presented in an input file-list.

Earlier you used the option

I've tested the Call for command "%TotalCmd% /O /T /S LOADLIST:%DestinationFile%"

It also should not have issued a notification for non-existent files.

What command do you use for the test now? And show us the contents of your list file please!

[AntonyD]

2sa16
The problem was discovered at the level of using another functionality - that's why I write that I have already tried all the options of this command - both in terms of writing format, application places, and the encoding of the used list-file. And I clearly stated that I SAW these messages when testing all these options. That's it. There's nothing more to clarify here.

The contents of my file are not tied to the bug entity in any way. Not at all. There is something on the level of some internal checks that were somehow implemented in the code of Total. Because with the help of Process Monitor, it was clearly seen that all records were read and processed, including checking the real attributes of the files on the disk - everything was obtained, everywhere SUCCESS. BUT at the output stage - for some reason, the list was reduced to the entries that are related to the E:\ partition. That's it. Now the only question is for the developer - either we will do this EXACTLY - by logging the code behavior on the test machine and on mine - and compare these logs. OR the whole topic will be moved to its proper section of this forum "will not be changed". I'm tired of guessing.

[sa16]

2AntonyD
Is it really difficult to lay out a command and one line from a file that is not displayed?
I will create my own file with this line and see the result of working with your command.
Drive E:\ I have!

[white]

2AntonyD
Is it really difficult to lay out a command and one line from a file that is not displayed?
I will create my own file with this line and see the result of working with your command.
Drive E:\ I have!

From his statements I get that you can test it using: LOADLIST <filename>. There is no other command. Any file in any folder on drive E: will do, mixed in with other files or not.

2AntonyD
Did you try this:

5. When using
subst x: e:\
Can you then add files on drive x: via LOADLIST ?

It may help to further pinpoint the issue.

[sa16]

There is no other command.

For example, there are LOADLIST0 - no error messages.

[white]

There is no other command.

For example, there are LOADLIST0 - no error messages.

Which you ruled out because he gets an error message when the file does not exist.

[AntonyD]

2white

Did you try this:

quote of my prev. answer:

3) and 5) I will take the liberty of combining these points - since the result is the same - files from the new disk/letter do not appear
in the final output on the file panel of the "Search result:" tab.

2sa16
I've tested it on another compute with more than 3 partitions. And there 2 partitions did not work.
Problem is not related to some specific name/path/level of paths. What we can for sure to say - IF
on you computer you CAN get output on a tab "Search results:" via LOADLIST command - from ALL
available partitions - then this means that this bug is not reproduceable on your side.

and white noted everything accurately. "Any file in any folder on drive E: will do, mixed in with other files or not."

there are LOADLIST0 - no error messages.

yep, but we do NOT use it for current testing purposes. Exactly because it blocks output of error/warning messages.