Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

DIFFER questions....

I haven't got a clue, Charles. The ONLY errors I get are "access denied" ones, which are expected.

Your results are very strange. @FULL doesn't care about paths.
Code: 
v:\> echo %@full["c:\I don't exist\Neither do I"]
"C:\I don't exist\Neither do I"

Only the DO tries to follow any paths and I can't imagine why that would screw up.

Your INI file looks OK to me.
 
I don't understand the access denied errors. All the BTM does is to basically do a dir /a: /s so I am not trying to open the file.

I have a system managed swap file, wonder what else might be different between our systems or what might be causing my errors
 
"Access denied" errors make sense. To SEE files you have to open (implicitly) a directory; more precisely, you have to open a search HANDLE. There are many directories on the system drive whose contents can't be listed by an unelevated process. I suspect FindFirstFile() (which should give a HANDLE to a search) in failing in these cases.

But you said you were getting "path not found" errors. That one I don't understand.
 
Charles G said:
Any thoughts on how I could debug what is going on?
Click to expand...
You could try to manually access those directories that were reported as having a bad path ...

or a do-almost-nothing DO loop ... see if you get the same problems.
Code: 
do f in /d"%1" /a: /s *
    set quoted=%@full["%f"]
    echo %quoted
enddo
 
this is why I can't access one of the folders.....

then I got the outpuit and errors as in the ZIP file...
 

Attachments

  • Capture.PNG
    Capture.PNG
    105.7 KB · Views: 232
  • DupFind.zip
    DupFind.zip
    2.7 KB · Views: 232
I have no idea why you have a problem with
Code: 
""C:\DataBackup\Program Files (x86)\Hewlett-Packard\HP Setup\ZH_TW_eula.html""
""i:\\Program Files (x86)\Hewlett-Packard\HP Setup\ZH_TW_eula.html""
I have no idea where these are coming from. The BTM is quite straightforward.
Code: 
TCC: (Sys) C:\Users\Galloway\Desktop\DupFind\testing.btm [2]  The system cannot find the file specified.
 ""
TCC: (Sys) C:\Users\Galloway\Desktop\DupFind\testing.btm [2]  The system cannot find the file specified.
 ""
TCC: (Sys) C:\Users\Galloway\Desktop\DupFind\testing.btm [2]  The system cannot find the file specified.
 ""
And I have no idea why you get "path not found" errors. I get "access denied" on several of those.
 
I am using win7 Home Premium, but mine is 64b - yours is 32, right?

Do you do anything funky with your system?

Can someone else try the BTMs I posted earlier tonight and see what they get please?
 
It probably has something to do with having two " characters together. Instead of
Code: 
set quoted=%@full["%f"]
,
try
Code: 
set quoted="%@unquote[%@full[%f]]"
 
Yes, my Win7 is 32-bit. I do a lot of funky things, but none which should affect something this basic. I conduct my tests as an admin, unelevated.

This (below) and several similar examples still surprise me. Using your testing.btm and collecting the error messages
Code: 
do f in /d"%1" /a: /s *
    set quoted=%@full["%f"]
    echo %quoted
enddo

You see:
Code: 
TCC: (Sys) C:\Users\Galloway\Desktop\DupFind\testing.btm [4]  The system cannot find the path specified.
 "C:\ProgramData\Microsoft\WwanSvc\Profiles\"

And I see:
Code: 
TCC: (Sys) C:\Users\vefatica\Desktop\testing.btm [4]  Access is denied.
 "C:\ProgramData\Microsoft\WwanSvc\Profiles\"

Maybe this is because of some 32/64 file system smoke and mirrors, but I don't understand it. In your case, it seems contradictory ... DO finds it and finding it triggers a "cannot find the path" error.
 
I run as an elevated, non-Administrator user account...

I have ran the BTMs in dupfind.zip and the output and error logs are in outs.zip....
 

Attachments

Any more thoughts to those who looked at the ZIPs I uploaded yesterday?
 
Charles G said:
Any more thoughts to those who looked at the ZIPs I uploaded yesterday?
Click to expand...
I've seen the results several times and I can't explain ...
1. why you get the "path not found" message in situations where I get an "access denied" message.
2. what the problem is with "C:\DataBackup\Program Files (x86)\Hewlett-Packard\HP Setup\ZH_TW_eula.html"
 
Now I am getting errors again.....

Code: 
Processing I:\ProgramData\Microsoft\Diagnosis\DownloadedSettings\cfc.flights.json
Processing I:\ProgramData\Microsoft\Diagnosis\DownloadedSettings\telemetry.ASM-WindowsDefault.json
Processing I:\ProgramData\Microsoft\Diagnosis\DownloadedSettings\telemetry.ASM-WindowsDefault.json.bk
Processing I:\ProgramData\Microsoft\Diagnosis\DownloadedSettings\utc.app.json
Processing I:\ProgramData\Microsoft\Diagnosis\DownloadedSettings\utc.app.json.bk
Processing I:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\AutoLogger-Diagtrack-Listener.etl
"I:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\AutoLogger-Diagtrack-Listener.etl"
"c:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\AutoLogger-Diagtrack-Listener.etl"

[C:\Users\Galloway\Desktop\DupFind]echo %_?
0

[C:\Users\Galloway\Desktop\DupFind]dir c:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\auto*

 Volume in drive C is OS           Serial number is 8293:971b
TCC: (Sys) The system cannot find the file specified.
 "C:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\auto*"
                   0 bytes in 0 files and 0 dirs
     314,848,563,200 bytes free

[C:\Users\Galloway\Desktop\DupFind]dir /a: c:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\*auto*

 Volume in drive C is OS           Serial number is 8293:971b
TCC: (Sys) The system cannot find the file specified.
 "C:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\*auto*"
                   0 bytes in 0 files and 0 dirs
     314,848,563,200 bytes free

[C:\Users\Galloway\Desktop\DupFind]list outs\idrive_cdrive.txt

I had a thought - be nice to get the error message or code displayed as we,ll as the two file names...... I am thinking those are temp files

The latest BTM is attached too.
 

Attachments

I modified the line in the BTM to this:

Code: 
on error ( echoerr %_? : & echoerr "%full" & echoerr "%target" & pause )

and on the error line above the %_? returns 2 - so how can a file not be found?
 
Charles G said:
I modified the line in the BTM to this:

Code: 
on error ( echoerr %_? : & echoerr "%full" & echoerr "%target" & pause )

and on the error line above the %_? returns 2 - so how can a file not be found?
Click to expand...
Assuming the file actually exists, could the file name in question contain a special character such as '%' ?
This would cause the "TCC: (Sys) The system cannot find the file specified" error.
 
Charles G said:
I had a thought - be nice to get the error message or code displayed as we,ll as the two file names
Click to expand...
Won't ON ERRORMSG instead of ON ERROR do that? I think you were doing that way back near the beginning of this thread.
 
in an elevated CMD session - I went to that folder and that file did not exist.... even with DIR /a:

What is going on - anybody?
 
Charles G said:
in an elevated CMD session - I went to that folder and that file did not exist.... even with DIR /a:

What is going on - anybody?
Click to expand...
What folder? How can you go to it if it doesn't exist. If you can navigate to it in Explorer, look at its attributes, its security. See if it's a junction, or inside a junction. Try to CDD to it. CDD to its parent and do a simple DIR.
 
No hashing function will tell you if files are "THE same". It will only tell you if they are LIKELY the same.
To find out if they are truly same, you will have to do a byte comparison.
 
vefatica said:
What folder? How can you go to it if it doesn't exist. If you can navigate to it in Explorer, look at its attributes, its security. See if it's a junction, or inside a junction. Try to CDD to it. CDD to its parent and do a simple DIR.
Click to expand...

The folder is "c:\ProgramData\Microsoft\Diagnosis\ETLLogs\ShutdownLogger\" as I mentioned in the post #45. The folder does exist just not the "AutoLogger-Diagtrack-Listener.etl" nore any other files actually.

Trying to access the folder with Windows Explorer, get as far as "Diagmosis" and then told I do not have permission to access the "ETLLogs" folder. So how can I have the script not try to access ones I do not have permission to access?

AnrDaemon said:
No hashing function will tell you if files are "THE same". It will only tell you if they are LIKELY the same.
To find out if they are truly same, you will have to do a byte comparison.
Click to expand...

So back to using @CRC32 ?
 
I suspect the file exists. Else, how would TCC get its name? But the "how" part is a mystery to me.

There are other things I don't understand. Is it correct that when elevated, I have "Admin" permissions? Here are some permissions for "c:\users\default user".
1516047935144.png


But in an elevated TCC session ...
Code: 
c:\users\default user> echo %_elevated
1

c:\users\default user> echo foo > foo.txt

c:\users\default user> dir /k /m *
TCC: (Sys) The system cannot find the file specified.
 "C:\Users\Default User\*"

c:\users\default user> type foo.txt
TCC: (Sys) Access is denied.
 "C:\Users\Default User\foo.txt"

c:\users\default user> attrib foo.txt
TCC: (Sys) Access is denied.
 "C:\Users\Default User\foo.txt"

c:\users\default user> echo %@attrib[foo.txt]
___A___________

That is, I can write the file, but not see it or read it. And I have no idea why ATTRIB fails when @ATTRIB succeeds.
 
This is off-topic, but (I hope) mildly interesting.

Earlier in this thread, we discussed checksums and I gave a simple argument that no finite combination of finite-length hashes could be without collisions (different files with the same hash). I wanted to see a specific example. After a day of searching for a CRC32 algorithm that matched TCC's @CRC32[] (plus translating, programming, and testing) I found the one I wanted described in RFC1952.

CRC32 has 2^32 different values and there are 256^5 = 2^40 different 5-byte files. There has to be collisions. With no guarantee of success, I set out to look for a 5-byte collision with "abcde" that used nicely printable characters. I got lucky. It took a ~50-line program 45 seconds to discover this.

Code: 
v:\> echo %@filesize[abcde.txt]
5

v:\> echo %@filesize[other.txt]
5

v:\> type abcde.txt
abcde

v:\> type other.txt
}-?eq

v:\> echo %@crc32[abcde.txt]
8587D865

v:\> echo %@crc32[other.txt]
8587D865
 
rconn said:
Which is why TCC doesn't uses CRC32 internally for anything.

If your program tries to duplicate that feat with SHA512, you are going to need to wait a bit longer ...
Click to expand...
Yup! Considering that 65-byte files would be analogous, and again using only characters 33~126, a rough guess would be

Code: 
24415814458511853031212217774297452627359068628009699173162412638385920137458858765365344460498378437353024168893874176

times as long (again with no guarantee of success).
 
I guess compare[] compares byte-by-byte and stops where there is a mismatch.

Vince - how about trying to find a simple collisions for sha512 ?
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate