voidtools forum

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

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,<)) return (0); memset (&tm, '\0', sizeof(tm)); tm.tm_...

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 (c) David ...