inconsistent behaviour: indexes->ntfs and indexes->folders

Found a bug in "Everything"? report it here
Post Reply
hundreAd
Posts: 3
Joined: Tue Aug 18, 2015 6:57 pm

inconsistent behaviour: indexes->ntfs and indexes->folders

Post by hundreAd »

(Everything-1.3.4.686)

using indexes->ntfs on drive c finds only the 1st hard link (as already mentioned elsewhere on the forums).
however, indexes->folders on drive c correctly finds all hard link.

2 ways to do what should be the same thing, BUT with different results... at least the latter returns correct results...
not to mention, what is the logic with this only-1st-hardlink idea? VERY bad idea: think of trying to delete a file with 100 hardlinks or searching for *.ttf and finding none in c:\windows\fonts...
therube
Posts: 4955
Joined: Thu Sep 03, 2009 6:48 pm

Re: inconsistent behaviour: indexes->ntfs and indexes->folde

Post by therube »

> different results

Known.
I believe intent is for that to change in the next version?

> trying to delete a file with 100 hardlinks

That would be difficult (with Everything).
Have another utility that will enumerate all 100?
LSE, perhaps, then you could copy what it found & make a batch file out of it, to whack them all. (Or does Windows offer facilities to "recursively" delete links until the file is gone?)

> *.ttf and finding none in c:\windows\fonts...

Possibility exists that that can occur.
therube
Posts: 4955
Joined: Thu Sep 03, 2009 6:48 pm

Re: inconsistent behaviour: indexes->ntfs and indexes->folde

Post by therube »

LSE, perhaps
Well, looks like the command line version of it, LN, includes a batch file already, DeleteAllHardlinks.bat:

Code: Select all

@echo off

REM
REM Check for commandline args
REM
if "[%~1]" == "[]" goto error

set LN=ln.exe

REM
REM List hardlink sibblings and delete all siblings
REM
for /f "delims=" %%a in ('@%LN% --list "%~1"') do (
  del /f "%%a"
)

goto ausmausraus

:error
echo DeleteAllHardlinks: Argument is missing. Usage DeleteAllHardlinks ^<filename^>
echo e.g. DeleteAllHardlinks c:\data\myfile.txt

:ausmausraus
echo on
http://schinagl.priv.at/nt/ln/ln.html
hundreAd
Posts: 3
Joined: Tue Aug 18, 2015 6:57 pm

Re: inconsistent behaviour: indexes->ntfs and indexes->folde

Post by hundreAd »

there is no need to wait for new version, or have problems with hard links. everything is ALREADY implemented, that is my point.

simply use indexes->folder and add drive c:, now everything is found without a problem: if a file has multiple links, all are shown, and thus can be easily deleted.

(of course indexes->ntfs should be disabled for drive c when using the indexes->folder approach)
therube
Posts: 4955
Joined: Thu Sep 03, 2009 6:48 pm

Re: inconsistent behaviour: indexes->ntfs and indexes->folde

Post by therube »

if a file has multiple links, all are shown, and thus can be easily deleted
And just how are these multiple links enumerated (in Everything) such that you know that they are in fact hardlinks of one another & not some file in a different directory that ... that what ... may happen to have the same name, size & date?

And what is the purpose of this searching in order to delete?

Everything can find same named files very simply, using the dupe: function (& I can't imagine that takes hardlinks into consideration), but note that what is found will be duplicates by name only.

So if you were looking to delete hardlinks (currently) Everything will not suffice.

When/if Everything does detect all the hardlinks to a file, & assuming it enumerates them in some fashion (a new column; hardlink ID# or some such), then you can be assured that the same 'hardlink iD#'d' files are just that. And if you deleted all of the same ID#, then the file would be gone, or if you deleted all but one, then only one (directory entry) of that file would remain in existence.
hundreAd
Posts: 3
Joined: Tue Aug 18, 2015 6:57 pm

Re: inconsistent behaviour: indexes->ntfs and indexes->folde

Post by hundreAd »

just create some hardlinks yourself and see:

Code: Select all

C:\x>echo blah > 11

C:\x>mklink /h 22 11
Hardlink created for 22 <<===>> 11

C:\x>mklink /h 33 11
Hardlink created for 33 <<===>> 11

C:\x>mklink /h 44 11
Hardlink created for 44 <<===>> 11

C:\x>mklink /h 55 22
Hardlink created for 55 <<===>> 22

C:\x>dir
19/08/2015  21:50                 7 11
19/08/2015  21:50                 7 22
19/08/2015  21:50                 7 33
19/08/2015  21:50                 7 44
19/08/2015  21:50                 7 55
now try finding with NTFS: only 11 is found.
disable NTFS and add C:\ to FOLDERS: 11, 22, 33, 44 ,55 are all found.
(if you do not disable NTFS you fill find 11 twice)

as to why delete, for example get rid of some windows crap (that is of course hardlinked so deleting just one won't help)

the original point was that you can just substitute whatever function NTFS is using for the FOLDERS function and be done with no effort on the development (assuming of course there are no issues with FOLDERS that NTFS does handle properly)
therube
Posts: 4955
Joined: Thu Sep 03, 2009 6:48 pm

Re: inconsistent behaviour: indexes->ntfs and indexes->folde

Post by therube »

now try finding with NTFS: only 11 is found.
disable NTFS and add C:\ to FOLDERS: 11, 22, 33, 44 ,55 are all found.
(if you do not disable NTFS you fill find 11 twice)
Yes, that's all understood.
as to why delete, for example get rid of some windows crap (that is of course hardlinked so deleting just one won't help)
Getting rid of crap is fine.
Getting rid of hardlinks, 10 out of 11, or 999 out of 1000 will accomplish nothing, because that 1 file that you have left takes up no more & no less space then the 11 or 1000.
(And I would think that if you tried that with Windows OS [hardlink] files, you'd end up hosing your system.)

Now there may be less "eye" clutter, but that is all you would be accomplishing.

If you removed all 11 or all 1000, then in that case the file would cease to exist & the space it occupied would be returned to the OS.
you can just substitute whatever function NTFS is using for the FOLDERS function and be done with no effort on the development
I wouldn't know anything about that, other then there would be speed difference & not all updates would necessarily be caught, so you'd also have to keep that in consideration.


Any how, it is what it is, & it will be what it will be - in the future, better :-).
Post Reply