voidtools forum

> Does the issue persists with the latest SDK dlls?

No! That fixed it. Thanks.

> Does the issue persist?

Yes. I think it's a double-free. Since if I disable the line:
in the bottom of _Everything_SendIPCQuery2(), there is no bug-check.

And I've modified AppVerif to look for leaks; there are not any.

I'm using the Everthing SDK in my program envtool. Now I've added some appverif.exe tests for my program that shows some misuse (?) of the Process Heap by everything.c. First here are my appverif.exe settings: https://www.watt-32.net/misc/appverif-envtool.png And here's the call-stack on the AppVeri...

> This is likely some old cache of the Everything icon for localhost from the Everything HTTP server.

Seems plausible since I have briefly used the HTTP-server some time ago.

> Is this consistent, all the time, every day for weeks? Or do you just have a screwy icon cache today?

Happened only once.

> Can you reboot and try to reproduce?

Will try later.

While running Tor (with it HTTP-tunnel) and using Thunderbird email-program to sign in to Yahoo (some OAuth stuff), Chrome showed the logo (favion.ico?) of EveryThing !! http://www.watt-32.net/misc/Chrome-Everything-log.png How is this possible? I did not enable the HTTP-server in EveryThing, but on...

Thanks for the reply.

I found some other message for this problem.
I edited Everything-1.5a.ini and changed alpha_instance=1 to alpha_instance=0.

> In Everything, from the Tools menu, under the Debug submenu, click Stop Debug Logging.

On the other hand, if I stop debugging by pressing ^C, EveryThing exists (or crashes?).
Is this normal?

In my Envtool program I use this code to check if EveryThing is running: HWND wnd = FindWindow (EVERYTHING_IPC_WNDCLASS, 0); if (wnd) { ... } else printf (" Everything search engine not found.\n"); This works fine in ver 1.4.x. But not in v.1.5.0.1294a (x64). So has the ABI changed? Speaki...

Thanks for the link.

> You can use the FEAT command to check if the ETP/FTP server supports the EVERYTHING extension.

In the FEAT reply I get this:
What do each of these mean?

That's good.

I just installed the Deleaker memory/debug tool. When using the Everything-SDK in my program, Deleaker reported a memory-leak for the _Everything_cs critical section setup in _Everything_Initialize() . Since this is never deleted, I patched Everything.c into this: void EVERYTHINGAPI Everything_Clean...

Your test.py works fine in my Python 3.6.5. But not in Python 2.7.15 !?
Wounder why....

I've done some patches to the EveryThing SDK for turning down the warnings etc. from various non-MSVC compilers: CygWin - tested with gcc ver. 7.4.0. Both x86 and x64. Clang - tested with ver. 8.0.0. Both x86 and x64. PellesC - tested with ver. 8.00.170. OpenWatcom - tested with ver. 2.0 beta. Other...

void wrote:content: will only search files that you have indexed.

I don't get it. Meaning I will get lots of duplicates if I really want the handy content:foo feature?

What are your results if you search for syserr.cpp? The same. Do you have a folder index which might be duplicating these results from Tools -> Options -> Folders? That seemed to be it. I had these: c:\Program Files c:\Program Files (x86) Removing them and selecting Rescan Now fixed it. But, I'm no...

i just tried the portable and regular installation in safe mode and nothing works . Are you a member of Microsoft's Insider Preview program? What Win-10 build version do you have? Run c:\> winver to find out. This should AFAICS be 1803, OS-build 17134.191 if you use the last stable version. The lat...

First, a million thanks for a super program and the EveryThing SDK which I use in my https://github.com/gvanem/EnvTool program. To the issue: I found many forum topics related to Duplicates . But not Duplicates together with content: ... '' Like in this screen-shot: http://watt-32.net/misc/Everythin...

I'm also not fluent in regex syntax. So it was easy for me to erroneously query like this: c:\\windows\\.*gcc*\.exe$ which returns this: c:\WINDOWS\sysnative\dnscacheugc.exe c:\Windows\System32\netbtugc.exe c:\Windows\System32\netiougc.exe c:\Windows\System32\setupugc.exe c:\Windows\SysWOW64\netbtug...

Ok.

I changed to port 2121 and that works very stable; no 10054/WSAECONNRESET codes.
I get good transfer speed too; an
envtool --evry --host 10.0.0.37 *

gives 26 MByte of data in 9 sec (154 000 files).
Which works out as approx. 22 MBit/s over a 54 Mbit/s WiFi. Not bad!

What version of Windows are you using? Win-10 on both client and server sides. Do you have the Windows firewall enabled? Yes. But I'm testing on my LAN for the moment. Do you have a ETP-test server I can test slower transfers with? That be nice! Thanks for the tip on /debug and /verbose . I do have...

I've also tried using the ftp-client that comes with Windows. It also shows the same problem. I.e. ETP-server does not send a 200 End at the end of all results. Verified with this test-etp.bat file @echo off if %1. == . ( echo Usage: %0: file-spec exit /b ) echo QUOTE USER foo > etp-commands echo QU...

Thanks for answering. You only have 540 *.exe :D . I've tried with both a higher recv-timeout (10 sec) and 16kByte recv-buffer: DWORD timeout = 100*1000; int rx_size = 16*1024; setsockopt (sock, SOL_SOCKET, SO_RCVTIMEO, (const char*)&timeout, sizeof(timeout)); setsockopt (sock, SOL_SOCKET, SO_RC...

I've integrated ETP-server support in my envtool search program. I find it works fine most of the time, but trying to get a list of all *.exe files on a remote server, the ETP-tranfer gets interrupted. The WSAGetLastError() is 10054 which is WSAECONNRESET I use a command like: envtool.exe --evry --h...

Thanks for the information. But that just proved more complex. With this: static time_t FILETIME_to_time_t (const FILETIME *_ft) { SYSTEMTIME st, lt; struct tm tm; if (!FileTimeToSystemTime(_ft,&st) || !SystemTimeToTzSpecificLocalTime(NULL,&st,&lt)) return (0); memset (&tm, '\0', siz...

Ok, that would be a good fix. I have a question on the time-zone. With this DATE_MODIFIED 131401049909872229 , I use this code to convert to a time_t : /* Number of seconds between the beginning of the Windows epoch * (Jan. 1, 1601) and the Unix epoch (Jan. 1, 1970). */ #define DELTA_EPOCH_IN_SEC 11...

It seems the value I got; 18446744073709551615
is (unsigned __int64)-1). I assume you have used this value to initialise an unknown folder-size.
(just to differentiate a folder-size of 0 byte). But then forgot to fill in the real folder-size. Or something like that, no?

Experimenting with remote queries using the ETP protocol, I've noticed the size reported on a FOLDER, is extremely large. In my case a c:\Windows\Panter\ folder contains 18446744073709551615 bytes. Which is approx. 15 Etta Bytes!! Tested using this test-etp.bat file: @echo off echo USER foo:bar > et...

Compiling everything.c with WINVER=0x0601 (or WIN32_WINNT=0x0601), gives these errors from MSVC-2015: Everything.c(43): warning C4005: 'MSGFLT_ALLOW': macro redefinition f:\ProgramFiler-x86\WindowsKits\Include\10.0.15063.0\um\winuser.h(15076): note: see previous definition of 'MSGFLT_ALLOW' Everythi...

Everything IPC is always 32bit (even on 64bit Everything). You mean because the windows handle is always 32-bit? Any reason why you need to know if Everything is 32bit or 64bit? A 32-bit EveryThing can return files in e.g. %SystemRoot%\sysnative which makes little sense to a 64-bit calling program....

It would be nice to have an IPC message to get information on the bitness of EveryThing. I.e. if it is a 32-bit or 64-bit version.

Maybe Everything_Reset() should also call TerminateThread() if the
_Everything_thread_proc() is still alive at that point?

Regarding this EnvTool of mine ( https://github.com/gvanem/EnvTool ) I would like to include some more statistics in my "envtool --version" output. I already have this: Version 0.96 (Visual-C, release, Win32) by Gisle Vanem <gvanem@yahoo.no>. WOW64. Everything search engine ver. 1.3.4.686 ...