Hi, you can use the regular-expression search functionality to specify a pattern like this: >.*\\[^\\]*\.(jpg|png)$
This seems unrelated to this program. And without any way to reproduce it I don't think there's anything I can do.
This seems unrelated to this program.
This seems unrelated to this program.
Those are not duplicates; they are different streams of the same directory. This is by design.
Yes, the program only captures a snapshot of the filesystem at a given point in time. It doesn't dynamically update. This is by design and difficult to avoid.
Hi there! Thank you for reaching out! I actually haven't yet established a general commercial license or pricing model (though I may do so as I see recent interest!), but I'm of course happy to license it on a case-by-case basis for your company. If you could please read the following and message me directly with the aforementioned information so I can understand your intended use, I'd be grateful & more than happy to discuss potential options: Will you need the license to include any kind of ongoing...
I remembered something: you can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: Via an app like CFF Explorer Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position...
I remembered something: you can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: Via an app like CFF Explorer Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position...
I remembered something: you can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: Via an app like CFF Explorer Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position...
I remembered something: you can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: Via an app like CFF Explorer Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: Via an app like CFF Explorer Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position = $x + 0x5C; $f.WriteByte(0x3);...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: - Via an app like CFF Explorer - Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position = $x + 0x5C; $f.WriteByte(0x3);...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this in any of 3 ways: - Via an app like CFF Explorer - Via PowerShell: $f = [System.IO.File]::Open('C:\SwiftSearch.exe', [System.IO.FileMode]::Open); $f.Position = 60; $x = 0 + $f.ReadByte(); $x += $f.ReadByte() * 0x100; $f.Position = $x + 0x5C; $f.WriteByte(0x3);...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this via an app like CFF Explorer, or if you have Python, via a command like the following: python -I -c "import struct, sys; f = open(sys.argv[1], 'r+b'); f.seek(60); f.seek(struct.unpack('I', f.read(4))[0] + 0x5C); f.write(struct.pack('H', int(sys.argv[2])));"...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this via an app like CFF Explorer, or if you have Python, via a command like the following: python -I -c "import struct, sys; f = open(sys.argv[1], 'r+b'); f.seek(60); f.seek(struct.unpack('I', f.read(4))[0] + 0x5C); f.write(struct.pack('H', int(sys.argv[2])))"...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this via an app like CFF Explorer, or if you have Python, via a command like the following: python -I -c "import struct, sys; f = open(sys.argv[1], 'r+b'); f.seek(60); f.seek(struct.unpack('I', f.read(4))[0] + 0x5C); f.write(struct.pack('H', int(sys.argv[2])))"...
You can actually use other versions of the program (including 7.5.1) as a console program too. The only thing you need to do is to change the "Subsystem" bit in the .exe's "optional header" from 2 (Windows GUI) to 3 (Windows Console). You can either do this via an app like CFF Explorer, or if you have Python, via a command like the following: python -I -c "import struct, sys; f = open(sys.argv[1], 'r+b'); f.seek(60); f.seek(struct.unpack('I', f.read(4))[0] + 0x5C); f.write(struct.pack('H', int(sys.argv[2])))"...
There's nothing more recent than version 1.5 I believe, unfortunately.
I don't know what it could be unfortunately... how old are the versions you've tried? Have you tried version 6.4? 1.3? Does this really occur on those too?
Thanks for reporting! Unfortunately I'm not sure. Does this occur immediately when you start the program, or does it happen when you do something? Have you tried running an older version to see if it works for you?
Yup!
Great question! Blue/green are the same as in Explorer. (By default blue means NTFS-compressed, and green means encrypted.) Teal (actually it's the midpoint between the above two colors^, which is teal by default) means the file has the "sparse" flag set. This can happen either because the file is a sparse file, or because the data is stored in a special way. For example, Windows 10's CompactOS feature (WOF compression) can set the "sparse" flag, so this can also indicate your data is using WOF compression....
You can start your pattern with >(?!.*:Zone\.Identifier$) to exclude :Zone.Identifier streams. Note that anything after this will match the entire path (not just file name).
You can start your pattern with >(?!.*:Zone\.Identifier$) to exclude :Zone.Identifier streams.
The list is rather static currently, so changes won't be visible in it. But you should be able to delete files by right-clicking them and selecting Delete. You just won't see the changes until you refresh SwiftSearch.
Yes, the list is rather static currently.
Hi, As far as danger is concerned, no, the program should never have been dangerous. It only opens the volume directly for reading -- it doesn't try to bypass the filesystem for writing purposes. But I'm pretty sure I have indeed fixed a wide variety of issues in everything from NTFS reading to the indexing, matching, UI, and everything else. I don't have all the changes memorized, and I don't necessarily even list them in the release notes, but I can tell you that you're running buggy versions I...
I am OK to just name it the way you suggsted incl. all other changes to the code and only share binaries... if that is what you want. Yes thanks, I'd appreciate that. I admit I might be wrong about this... but hopefully there won't be too many people who will come to me for bugs that you might have introduced. I guess I'll take the risk and see :-) thanks!
Isn't using a "totally different name" the exact opposite of what I wrote? :\ I was just trying to explain, if SwiftSearch isn't in the name, then it will look like your version is the original. 99% of users will not look inside Help->About; they just look at the software name. They won't have a clue what you're giving them is really SwiftSearch with some modifications. Why not do "SwiftSearch (Robert Nio edition)" or something like that? That's what I suggested, not replacing the name entirely with...
Isn't using a "totally different name" the exact opposite of what I wrote? :\ I was just trying to explain, if SwiftSearch isn't in the name, then it will look like your version is the original. 99% of users will not look inside Help->About; they just look at the software name. They won't have a clue what you're giving them is really SwiftSearch with a few modifications. Why not do "SwiftSearch (Robert Nio edition)" or something like that? That's what I suggested, not replacing the name entirely...
Isn't using a "totally different name" the exact opposite of what I wrote? :\ I was just trying to explain, if SwiftSearch isn't in the name, then it will look like your version is the original. 99% of users will not look inside Help->About; they just look at the software name. Why not do "SwiftSearch (Robert Nio edition)" or something like that? That's what I suggested, not replacing the name entirely with your own.
Isn't using a "totally different name" the exact opposite of what I wrote? :\ I was just trying to explain, if SwiftSearch isn't in the name, then it will look like this is the original. 99% of users will not look inside Help->About; they just look at the software name. Why not do "SwiftSearch (Robert Nio edition)" or something like that? That's what I suggested, not replacing the name entirely with your own.
Isn't using a "totally different name" the exact opposite of what I wrote? :\ I was just trying to explain, if SwiftSearch isn't in the name, then it will look like this is the original. 99% of users will not look inside Help->About; they just look for the software name. Why not do "SwiftSearch (Robert Nio edition)" or something like that? That's what I suggested, not replacing the name entirely with your own.
Isn't using a "totally different name" the exact opposite of what I wrote? :\ I was just trying to explain, if SwiftSearch isn't in the name, then it will look like this is the original. Why not do "SwiftSearch (Robert Nio edition)" or something like that? That's what I suggested, not replacing the name entirely with your own.
Binary is better, yeah. Let's think this through. So if you change the name entirely, ordinary users aren't going to know it's a modification of this project without digging into the authorship details (which most people won't do). But of course, if you keep the name, then it's going to confuse users and think it's an official release. Here's an idea: Could you change the name to something like "SwiftSearch (Robert Nio's version)", or similar? That way the original and also the modification are both...
I'm not sure about the regex unfortunately... I'd have to debug it when I get the chance and see. Regarding your GitHub idea though, I'm actually not OK with it; please don't do that. It's not something I want to see happening right now. If you'd really like to share your changes, you can post a .patch file here, but I think some of your changes (such as your quoting) are very specialized to your use case and will likely break if applied to other users. I would just use the tool for your own pur...
I'm guessing it's probably your Boost version. I think I must've used 1.68 for my binaries. You might want to add that feature yourself locally since I might not be adding it in the near future.
I'm guessing it's probably your Boost version. I think I must've used 1.68 for my binaries. You might want to add that feature yourself since I might not be adding it in the near future.
Ohh I had no idea you're talking about the CLI version! Please mention that when that's the case. I'm not sure to be honest, you might need to debug this yourself. Could you show the actual invocation of the console version? Your console window isn't really a screenshot of the program but a screenshot of something else you made.
What error are you seeing exactly? Would you mind posting a screenshot? Also, I think everything is already case-insensitive? I'm not sure there's any way to make it case-sensitive.
Sorry haha. If you mean as a std::tstring (i.e. std::basic_string<TCHAR>), you can always just use the iterators (std::tstring(s.begin(), s.end())). If you actually mean std::string then you'll also need an encoding conversion (most likely you want UTF-8?) in which case you can take a look at wcstombs in string_matcher to see how to do it.
Ah this just seems like a new feature than a bug. I'm glad it's useful :) but it requires a lot of screen space so I'm not sure about adding it. Thanks for sharing it though!
Thanks for considering! :) I think most of these are somewhat subjective customizations, so I'm not sure about adding them right now. However, the last 2 GUI items you listed seem like possible bugs that need to be addressed. Would you mind sharing "before" + "after" screenshots for the "Fit columns to Window" change, as well as the column width change? I'd be interested in seeing what the problem was and what it looked like after your fixes. Thank you!
That's impossible. There are already lines that do line_buffer.push_back(_T('\t')) so line_buffer.push_back(_T('\''))shouldn't be any different. I think you're typing something incorrectly. Are you using push_back like I wrote?
Oh sorry, just use line_buffer.push_back(_T('\'')); instead.
See my previous reply.
Try including the subsequent line: line_buffer += _T("'"); line_buffer += root_path; i->get_path(key, line_buffer, false); line_buffer += _T("'"); I wouldn't recommend surrounding with ', though. Single quotes are valid path characters. If you have to do this, I would suggest double-quotes instead. (Actually those are also valid inside alternate data streams, but unlikely to occur in practice.)
Glad to hear! And sorry the code is a little (very) messy ;)
My current local Boost version (which seems to work fine) was 1.72 as I mentioned earlier, but I think I might've been using Boost 1.68 for the last release? You'll have to debug it yourself :-) have fun debugging!
The console version is _tmain, the GUI version is _tWinMain, both are there. It's just a question of whether you link with /Subsystem:Console or /Subsystem:Windows. :-)
Hmm, I think that one might require following the Boost setup instructions? On my machine there is a boost subdirectory that has symlinks inside it pointing to the individual contents of the libs subdirectory. I think it might've been generated with b2.exe or bjam.exe, but you might be able to just run mklink /D C:\Boost\boost libs and get it to work that way, I'm not sure.
Ah sorry. Just add it after the <XPDeprecationWarning> line instead. For Boost, extract it somewhere (like C:\Boost; I think version 1.72 should work, but you can try other versions) and change the line: <PropertyGroup Label="UserMacros" /> to the following (make sure to include the final backslash): <PropertyGroup Label="UserMacros"> <BOOST_ROOT>C:\Boost\</BOOST_ROOT> </PropertyGroup>
I think you might have the wrong revision though. (Your folder suggests you have r636 instead of r467.) It might still work, but it might not.
Ah, don't add it to those. Open Project.props in a text editor, look for lines that say <IncludePath ...>, then add the following line after them: <IncludePath>C:\wtl-code-r636-trunk\wtl\Include;$(IncludePath)</IncludePath> I didn't have this in the project because I have WTL in my user-level includes (globally), sorry about that.
Ah, you need WTL for that. Try checking out this revision: https://sourceforge.net/p/wtl/code/467/
Haha, it was absolutely difficult to put this tool together. ;) I worked on it for many, many years. It wasn't even in C++ in the beginning; I had to rewrite it (multiple times I believe, but my memory has faded). :-) Finding documentation on NTFS was much more difficult when I wrote it too. And getting it to have such high performance took a long, long time. For the attributes, I'll have to see if I can add them... though I'm not sure where/how. I don't know if I even keep them all around in memory!...
Haha, it was absolutely difficult to put this tool together. ;) I worked on it for many, many years. It wasn't even in C++ in the beginning; I had to rewrite it (multiple times I believe, but my memory has faded). :-) Finding documentation on NTFS was much more difficult when I wrote it too. And getting it to have such high performance took a long, long time. For my toolchain, I don't think you need older Windows SDKs? I'm not even sure if you need the DDK; I think you should be able to just do a...
Haha, it was absolutely difficult to put this tool together. ;) I worked on it for many, many years. It wasn't even in C++ in the beginning; I had to rewrote it (multiple times I believe). :-) Finding documentation on NTFS was much more difficult when I wrote it too. And getting it to have such high performance took a long, long time. For my toolchain, I don't think you need older Windows SDKs? I'm not even sure if you need the DDK; I think you should be able to just do a normal Release build. Feel...
Hi, There's no way to call it as a DLL unfortunately. I didn't really intend it to be something to build more tooling on top of. By "extended attributes" Are you talking about $EA_INFORMATION, about WSL file attributes (chmod etc.), or about regular file attributes (FILE_ATTRIBUTE_NORMAL)? Although, I guess I don't really have much support for most of them... what exactly are you looking to be able to do?
Specify initial drive and search pattern through command line arguments
Yeah, I realize the code is pretty terrible ;) I've meant to refactor it for a long time (and it's why I made string_matcher.cpp a separate file, since it came much later), I just haven't had the time to do it since it's so painful.
Thanks for taking the time to implement this! However, I'm not sure I want to do it like this -- having a command-line argument pre-fill UI is rather unexpected behavior for any program. I do see the value in saving and restoring state, though. Perhaps I'll take another look at it at some point when I have a chance.
Regarding this: If you're a user looking for the patch, feel free to contact me at wfunction@users.sourceforge.net or send me a message via SourceForge.
That one could fail if there is a backslash in the stream name, which I think is possible but unlikely...
It's not that simple... if I did that then suddenly WoF-compressed files will appear to be 0 bytes, and the folder sizes wouldn't make sense or add up correctly. People would be completely confused when they compared to what they saw in Explorer. Also, you still wouldn't get a number of matches equal to "the number of real files" because of e.g. hardlinks. That said, you can currently do this with a regex... >^[A-Z]:\\[^:]*$ Or you can use this one, to explicitly exclude results with colons... >...
It's not that simple... if I did that then suddenly WoF-compressed files will appear to be 0 bytes, and the folder sizes wouldn't make sense or add up correctly. People would be completely confused when they compared to what they saw in Explorer. Also, you still wouldn't get a number of matches equal to "the number of real files" because of e.g. hardlinks. That said, you can currently do this with a regex... >^[A-Z]:\\[^:]*$
Thanks for the feedback. Not sure what you mean, but MUI has never been a resource embedded inside the executable. Rather, MUI is a file containing its own resources equivalent to those of the executable, and if it's absent, then the resources in the executable are used by default. As for ResEdit, it seems wrong? The MENU statement definitely seems to be referring to the correct menu resource...
I'm not sure if translation was affected but I changed how menus are loaded in version 7.5. Would be nice if someone could check if anything has changed.
Ah ok.
You can do >^.*\\(A|B)$ to search for the file names A OR B. A AND B doesn't really make sense... a file can't have two names. Not sure what you're trying to do there.
I assume that's 8GB free memory? Your memory capacity doesn't matter, what matters is how much memory you have free. Can you also check what is the maximum number of entries you can copy (approximately)? 200k vs. 5M is a huge difference.
I can copy > 5M file paths just fine. I assume you're on 64-bit? Does it even show the progress bar? Do you have enough memory? It can require something like 1.5 GB I think... For the help menu I think that's fine. Hotkey conflicts happen. Those items are not something users want to bring up repeatedly.
I can copy > 5M file paths just fine. I assume you're on 64-bit? Does it even show the progress bar? Do you have enough memory? It can require something like 1.5 GB I think... For the help menu I think that's fine. Hotkey conflicts happen. Those items are not something users can bring up repeatedly.
I can copy > 5M file paths just fine. I assume you're on 64-bit? Does it even show the progress bar? Do you have enough memory? It can require something like 1.5 GB I think...
You mean beyond the latest release? I don't do that, sorry.
Yeah okay I think I know what the issue is then. I'll try to fix it in the next version but it may be a while before I release another version.
Did it use to work in the previous version? Because I managed to reproduce a crash, but it seems to be due to a change I made a long time ago...
Does the 64-bit version work fine or no?
I'm not sure what you downloaded but the uploaded files appear to be correct?
Just treat the build date to be the version number. It's in Help->Bugs? Features?
Oh man that's an awful way to do it haha. I released a new version, I tried to fix this issue as well as the other recent issues in there. Maybe check to see if everything works properly?
Oh man that's an awful way to do it haha. I released a new version, I tried to fix the recent issues in there. Maybe check to see if everything works properly?
AH okay that's a different story. I wait for the window to show before I initialize the search, to make sure the user is actually seeing a window before I do anything. That way if something goes wrong they can force-close it immediately instead of the program running in the background without their realization. Therefore if the window is never shown this would never happen. I assume you're setting the STARTUPINFO struct to hide the window? I could check that struct to see if it specifies a hidden...
Oh wait you mean you posted it right now, I see it now.
I try to clear out the moderation queue when I remember, but it doesn't remind me unfortunately. However I currently don't see anything... are you sure you have something stuck there?
Yeah just relax :) once I upload a fix let me know if it still has issues.
Are you talking about the current pause? That part is a bug and I've already fixed it, I just need to release a new version. It's not actually waiting on the file system; there's no need for a timeout. I thought you're talking about the case where it's waiting on the file system to figure out the drive type. That's a different situation and I can't just kill it in that case. Just relax a bit, I think you're in too much of a hurry!
Are you talking about the current pause? That part is a bug and I've already fixed it, I just need to release a new version. It's not actually waiting on the file system; there's no need for a timeout. I thought you're talking about the case where it's waiting on the file system. I can't kill it in that case. Just relax a bit, I think you're in too much of a hurry!
Can I ask why you're so insistent on this?
Well GetDriveType is synchronous so how would I time it out? I'd have to spawn a thread and then kill that thread manually. It's a little bit like shooting a tire off a car. It works if it's stopped, but if it's moving then it might crash into something...
I'm not going to special case X:
I'm saying GetDriveType sometimes has to read the disk to figure out what the file system even is. I've seen that create freeze the program in some situations for a very long time.
Yes and GetDriveType would block the UI. It's not that I don't know how to get the file system (I already am!!!!!) it's that it would require accessing the disk and I don't want to block the UI on that.
I'm not really convinced I should knock it out. To me it should be treated similarly to any other unrecognized file system. I can obviously change the error message to be more clear on this but I don't see any need to treat it differently on a more fundamental level.
The file system doesn't tell me why it fails. It just says the it can't find the file. So I can't assume it's because it's a RAM drive (and I can't even really know when something is a RAM drive either).
Removing X: from the list would probably happen if/when I remove other non-NTFS drives from the list. I can't do it in the very beginning since I don't want to make the UI wait for the file system. I might be able to remove it later but it's kind of annoying due to the logic separation and it's not really high priority on my list.
Yeah I realize, it's just that it's far easier said than done. It might happen down the road but don't hold your breath.