blog: filename juggling part II

[nikos]

here's the comment area for today's blog spot found at
http://zabkat.com/blog/filename-counters-link.htm

[Kilmatead]

Another, perhaps more glib, solution would be to just have fewer children. Fewer children = fewer videos, fewer videos = more disc space, more disc space = more room for porn. Just an idea.

I'm also thinking you didn't think this all the way through (again)... unless I misunderstood the original idea, the idea of "preserving names" depends upon renaming the links, which depends upon re-ordering them according to creation date (or whatever). This is fine for hard-links as they automatically copy the CAM (Created/Accessed/Modified) dates of the original object, but Symbolic Links do not - they are all set to the creation time of the link itself, making them somewhat difficult to "sort" via the CAM columns.

That said, you inadvertently just created a use for my silly recent TouchReparsePoint utility, which is specifically designed to sync the Symbolic Link CAM's with those of their target objects, which would then allow you to sort the links any way you wish.

Somehow I doubt you intended that coincidence, but there you go.

[Kilmatead]

Umm - which then brings up another difficulty as in the post for that utility, I clearly stated that:

The day I produce anything practical and beneficial to humanity is the day I feed myself to
the lions for the shame I would so feel.

I hadn't actually planned on that happening the next bloody day - 'cause, like, you know, lions have teeth and stuff...

[nikos]

This is fine for hard-links as they automatically copy the CAM (Created/Accessed/Modified) dates of the original object, but Symbolic Links do not - they are all set to the creation time of the link itself, making them somewhat difficult to "sort" via the CAM columns.

well spotted! I will now have to change xplorer2 to set the modified date of the symbolic link to that of the file -- so that the demo video will work as promised

[Kilmatead]

Easy for you to say, you don't have a lion munching on your leg at the moment.

On a vaguely related note, as I virtually never use hardlinks, I never ran across this before, but when the hardlink is deleted, I seem to have a perpetual "Lock" overlay icon attached to the original objects. This icon doesn't seem to be easily removed without actually duplicating the file and deleting the original (at least I can't figure out another way to clear them).

The icons appear in WinExplorer as well, happens with hardlinks created using x2 or MKLINK, so I don't think it's an x2 problem. Is this just me, or what? The icons appear immediately upon deleting the hardlink.

Edit: Interestingly, this may be related to this post, wherein RightPaddock seems to have encountered a similar thing.

And in X2 Version 2 I am seeing an awful lot of security lock icon overlays on files that I don't see as having them in 1.87 or in Win Explorer - that could be to do with icon overlay priorities.

I have a vague memory of us having discussion years ago about icon overlay problems - cant recall details or how it was resolved - or maybe its just deja vu

Is there a simple way of clearing all overlay icons from files, or do I have to write a utility for that as well? (Before Lafcadio the Lion here gets to my elbow...)

[nikos]

I don't know the answer but if you don't use overlay icons you can turn them off from Tools > OPtions > Advanced page, that should make things a bit faster too

[Kilmatead]

The problem with that is that it kills all overlay icons - including useful ones. What would your wife say if you suggested throwing the baby out with the bathwater? Hmm? Hiding the problem is not solving the problem. Who's manning the help-desk around here?

A little more investigating shows that the Links [S] column number to those items does NOT decrement when the link is deleted, though it does increment when one is created (as expected). It's happily at 5 at the moment, even though no links exist.

Even stranger, if the file is <Ctrl+F6> moved, and then moved back, the overlay icon is removed - although the Links [S] column count remains at whatever it was (5).

Wacky.

(I don't think my poor brain is up for another COM adventure so soon after the last one. Never mind that Lafcadio is up over the knee now, and he's indifferent as long as he has me for lunch.)

But - just in case I feel like it later - where might I look to discombobulate this stuff in the API on a file-by-file basis? Any ideas?

[FrizzleFry]

I use hard links a good bit and I do not see the lock icons on either the original or the link(s), plus when I delete a link the link count column is decreased. Are you using a link utility like Link Shell Extension which does put icon overlays on links... not the lock thing but little arrows like the shortcuts overlay but in different colors. I am not using LSE now but I do install it every so often.

[Kilmatead]

No, I don't use LSE - the default link icons are annoying (being the same as those of shortcuts, which I've had removed for years now), but the lock is the "normal" lock icon which we all know and love - quite possibly the Distributed Link Tracking Client service (that thing responsible for finding lost links) is interfering - except the DLT service doesn't apply to anything other than normal links (at least as far as I can tell - it seems connected to OLE links, which might be part of the DDE rubbish that melted my brain the last time I looked at it) so I don't see how it could be involved - but one never knows. I haven't tweaked anything related to icon overlays (other than removing stock .LNK shortcuts).

Definitely not right that your Link counts decrement and mine don't - that seems key. Going to have to bury my nose in GetFileInformationByHandleEx methinks, and commune with the gods the hard way.

[FrizzleFry]

The only time I see the lock icon is when I have done a share with/nobody on a folder... I don't think I have ever seen it on a file.

[Kilmatead]

If this were Sesame Street, I'd say that today's posts were brought to you by the letter A, the letter C, and the letter L, better known, boys and girls, as the Access Control List. Without going into too much detail, this is a goulash, a smorgasbord, a borscht, a witch's cauldron of sticky gooey substances which all boil down to a couple of things: ACL Inheritance (not so much the permissions themselves, but who was the last one [not user, but permissive-entity] to look at Hardlink target's MFT-copy in the directory itself).

First of all, the question of incrementing/decrementing hardlink counts was easy to solve - if you send them to the recycling bin (was I paying attention? Was I? No...) they are still there, so the secondary MFT is left in limbo - enacting a hardlink on an object updates not only the object's MFT but also the pseudo-MFT in the directory itself, which is only a partial copy of the original object's attributes (or, in this case, the Link Count - i.e., part of propagation). This way the original-object's MFT is considered the One True God, while the rest are only updated sporadically on access (opening) - which explains why the icon disappears if the file is moved. Otherwise the overhead of a thousand hardlinks with a thousand different names in a thousand different locations all being updated at the same time whenever the original file is included in a directory listing (say updating explorer's listview) would be ridiculous.

Bottom line: Reset the ACL's and the icons go away. Sending hardlinks to the recycling bin is kind of like mommy taking away baby's teddy, and baby then going to daddy to get it back - except daddy doesn't tell mommy he gave it back, and mommy still thinks she has it, promises to give it back to baby later. The question of inheritance is only resolved when both of the parents (User and "System") agree the link has been dissolved (teddy returned, Link-Count returns to 1) and this doesn't always happen before one or both of them die in finale gunfight over custody and drug-money (just like every other modern family). The file (baby) still has his teddy, so he doesn't care, but he also still has his mother's IOU for the teddy (the lock icon given to him by the ACL) - and grandpa (proper admin housecleaner) doesn't step in to fix it all until the credits roll and he's had his brandy and cigar.

I don't think my poor brain is up for another COM adventure so soon after the last one.

Aren't Sundays supposed to be a day of rest? One stupid little icon overlay when testing Nikos' link renaming scheme! I just want to curl up and cry with my teddy now.

As usual, there will be someone who wants corroborating evidence, so feel free to start here (which, if nothing else, explains why Hardlinks are not cross-volume entities!)...

NTFS file system is a distinguished achievement of structuring: each system component is a file -- even system information. The most important file on NTFS is named MFT or Master File Table -- the common table of files. It is situated in MFT area and is the centralised directory of all remaining disk files and itself. MFT is divided into records of the fixed size (usually 1 KBytes), and each record corresponds to some file. The first 16 files are housekeeping and they are inaccessible to the operating system. They are named metafiles and the very first metafile is MTF itself. These first 16 elements MFT are the only part of the disk having the fixed position. It is interesting that the second copy of the first 3 records, for reliability (they are very important) is stored exactly in the middle of the disk. The remaining MFT-file can be stored as well as any other file at any places of the disk. It is possible to re-establish its position with its own help using the basis -- the first MFT element.

[RightPaddock]

DLT works on shortcuts, I often break them (not surprising given how many I sort of have of them) it pops in and repairs them when next they're accessed - even if they're in an archive it will offer to repair them.

I say sort of because most of them are themselves hardlinks; so when one instance of a given shortcut is repaired, they're all repaired. Some of them have reached the 1023 limit on number of hardlinks, so I have to create a duplicate shortcut.

I also have thousands of folder symlinks, DLT has never offered to repair any broken ones, any more than it ever offered to repair the thousands of junctions I once had

If you delete a hardlink the reference count wont decrement because the file still exists, in the recycle bin. I habitually trash hardlinks to overcome this phenomena.

If you don't like LSE's icon overlays then do what I do - provide your own, as of a year or two ago there's even a config utility provided so you don't have to go poking about in registry office to find them.

No hardlinks available in Protogon, know known as ReFS - hmmmm, back to the future, its those damn storage pools - no, not the storage pools into which you dump your spent fuel rods, the ones into which MS wants you dump your unpartitioned disk drives

BTW Symlinks were implemented in pre Vista Windows (NT4 I think), but they were concealed. But you can download Masatoshi Kimura's drivers (and the source) from the LSE site, and if they're installed then LSE will use them and voila you'll have symlinks on XP - it's been working on my antiquated compaq laptop for the last six months since I got dear old thing going again over last Christmas.

I just saw K's post in this thread where he references one of my posts from nigh on a year ago, where this lock icon issue (bug) was first raised - it would seem that the issue (bug) is still there :sigh:

RP

[Kilmatead]

...it would seem that the issue (bug) is still there

Well, if you wade into my subsequent messy post above, you'd see that I solved it (at least my end of the lock overlay) and identified the why of it - clearing the ACL's works every time - though I must say it's a lot simpler to just temporarily translocate the object.

As it happened (for me) in Win Explorer as well, I can't class this as an x2 problem as (outside of the mistake of sending hardlinks to the recycling-bin) I can't recreate it.

And, as you point out, ReFS is killing off hardlinks anyway so deaf ears will get deafer... ("deafer?" - eh, it's Monday...)

[RightPaddock]

...it would seem that the issue (bug) is still there

Well, if you wade into my subsequent messy post above, you'd see that I solved it (at least my end of the lock overlay) and identified the why of it - clearing the ACL's works every time - though I must say it's a lot simpler to just temporarily translocate the object.

As it happened (for me) in Win Explorer as well, I can't class this as an x2 problem as (outside of the mistake of sending hardlinks to the recycling-bin) I can't recreate it.

And, as you point out, ReFS is killing off hardlinks anyway so deaf ears will get deafer... ("deafer?" - eh, it's Monday...)

Sorry k - it was late, so when I waded into your post, I got stuck in the mire of it, rather than absorbing the gist of it.
Never mind, I've had a cup of kFilter coffee now so I've decrypted it.

I read somewhere, I suspect on an MS blog, that hardlinks are not needed in ReFS because you can use symlinks <sigh>
Maybe we will get pool-links. Anyone up for a game aqua-golf with nucleated bikini clad caddies.

Libraries will disappearing off your radar screen in 8.1, that'll make someone we know happy.
I've found them to be quite useful, but inevitably not in the way they were intended to be used.

RP