[Toybox] Maybe a ln addition if possible?

[Rob Landley]

On 1/24/20 1:16 AM, scsijon wrote:
>>> as time goes on the version of akdjagh changes to akdjagh-1.2.45,
>>> it's the same file, just with additions, it's not as if it's being replaced with
>>> a completely new file!
>>
>> Define "changes". Somebody deleted the old 1.2.34 and made a new 1.2.45
>> filename. Who?
> 
> NO, the existing 1.2.34 had additions added inside it and was saved inder the
> existing name-version, then it was renamed to 1.2.45 to show the new level it
> had reached.

Hardlinks follow renames. Symlinks do not. But whatever is doing the passive "is
renamed" could fix up (recreate) the symlink at the same time it renames the
file the symlink points to.

>>> and the link dies....
>>
>> Symlinks do not wildcard expand, no.
>>
>>> Is there a way of having this not happen or deal with it somehow?
>>
>> Who's _doing_ it? (A package manager?)
> 
> the package owner/coder

The person who wrote the package is logging into your system and modifying files
on your machine, personally, for every sintall?

A package manager is a program that runs on your machine. The package _owner_
isn't. The package owner is modifying files on _their_ machine, probably weeks
earlier, often on another continent.

>> Not sure I understand the problem. Changing the ln command probably wouldn't
>> help because it boils down to a syscall that creates a "this name -> that name"
>> mapping in the kernel's dentry layer, which is a "when this is resolved, go look
>> at this other specific name" that only even gets loaded when you resolve the
>> first name, and then only looks at the second specific name (which doesn't even
>> have to be there for the link to be created)...
> 
>  So it's not possible to have the script built, in that once the first link
> (name-only) has been created it could follow even when the versions of the same
> name-file are updated rather than replaced.

Hardlinks follow renames, symlinks do not.

But that's assuming the contents are modified in-place, thus having the same
inode. If you "modify the contents" by deleting and recreating the old file (as
just all text editors do, and sed -i, to break hardlinks. Generally a two step
"copy contents to new file" then "rename over old file" so people looking at the
original name never see a partially changed file, they get either all old or all
new, atomically)... If they do that, then no. There new file has a different
inode and there's no relationship between the old and new files except possibly
similar contents and a coincidental name.

It's not a script problem, it's that the script creates a symlink and then
exits. From then on if _other_ programs mess with what the script created, it's
a question of "how symlinks behave in the kernel", which hasn't significantly
changed in 40 years.

Rob