(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...
inconsistent behaviour: indexes->ntfs and indexes->folders
Re: inconsistent behaviour: indexes->ntfs and indexes->folde
> 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.
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.
Re: inconsistent behaviour: indexes->ntfs and indexes->folde
Well, looks like the command line version of it, LN, includes a batch file already, DeleteAllHardlinks.bat:LSE, perhaps
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
Re: inconsistent behaviour: indexes->ntfs and indexes->folde
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)
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)
Re: inconsistent behaviour: indexes->ntfs and indexes->folde
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?if a file has multiple links, all are shown, and thus can be easily deleted
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.
Re: inconsistent behaviour: indexes->ntfs and indexes->folde
just create some hardlinks yourself and see:
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)
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
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)
Re: inconsistent behaviour: indexes->ntfs and indexes->folde
Yes, that's all understood.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)
Getting rid of crap is fine.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 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.
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.you can just substitute whatever function NTFS is using for the FOLDERS function and be done with no effort on the development
Any how, it is what it is, & it will be what it will be - in the future, better .