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.
"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.
"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.
Any thoughts on how I could debug what is going on?
or a do-almost-nothing DO loop ... see if you get the same problems.
I have no idea where these are coming from. The BTM is quite straightforward.
TCC: (Sys) C:\Users\Galloway\Desktop\DupFind\testing.btm   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?
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.
TCC: (Sys) C:\Users\Galloway\Desktop\DupFind\testing.btm   The system cannot find the path specified.
TCC: (Sys) C:\Users\vefatica\Desktop\testing.btm   Access is denied.
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.
Any more thoughts to those who looked at the ZIPs I uploaded yesterday?
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"
The latest BTM is attached too.
and on the error line above the %_? returns 2 - so how can a file not be found?
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.
Won't ON ERRORMSG instead of ON ERROR do that? I think you were doing that way back near the beginning of this thread.
What is going on - anybody?
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.
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?
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".
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.
That's up to you. The longer the cipher, the less likely are collisions.
If I can not use any of the sha* routines for a byte for byte comparison - then what would anyone suggest?
If you have a really fast system with SSDs, you could use @compare. It might only take a few days if you don't have many files.
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.
Which is why TCC doesn't uses CRC32 internally for anything.
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 ?