Symlinking upper_changes

[geo_c]

I often copy my upper_changes from an internal install to USB drive install, and normally I'll do that by using @fredx181's backup/restore.sys script and copying the backup to the USB drive.

And then I might do something like tag the upper_changes name with which computer it came from. And then I might have two or three sets of [DescriptivePrefix]upper_changes sitting in a given install folder on the USB drive, and I'll rename one of them to plain old upper_changes and boot with it.

Then that got me thinking, and this would be easy for me to test, I just haven't done it yet, why not just symlink the [DescriptivePrefix]upper_changes > upper_changes?

It should work right?

And if it's no problem doing that, wouldn't that be an easy way to have a boot choice? Where a script resymlinks the upper_changes to a backup_changes before loading it?

Maybe not easy, but a thought.

[mikewalsh]

@geo_c :-

Should work OK IF it's always the same KL variant, I would have thought. But; a word of caution. Sym-linking doesn't always work quite the way you think it's going to.... I have personal experience of this!

Still, sounds like you have plenty of "originals" to fall back to. Give it a try. What's the worst that can happen?

If it works, that's great. If it doesn't.....no biggie.

Mike.

[geo_c]

@geo_c :-

Should work OK IF it's always the same KL variant, I would have thought. But; a word of caution. Sym-linking doesn't always work quite the way you think it's going to.... I have personal experience of this!

Still, sounds like you have plenty of "originals" to fall back to. Give it a try. What's the worst that can happen?

If it works, that's great. If it doesn't.....no biggie.

Mike.

I just set up a new machine and copied 5 OS's on to it, and experienced a little bit of the unpredictability of symlinks.

Since I link my themes into my OS's from a library stored on the install partition outside the persistant save, I booted and found the themes and icons didn't show and the OS reverted to fallback, and that's simply because the themes were linked to sda1 and my new install is on nvme0n1p2

And this is the reason for the purpose of portability, the standard puppy approach of including a /mnt/home symlink in /mnt is so helpful. It allows one to copy whole drives full of symlinked OS's and still have everything show up.

[mikewalsh]

@geo_c :-

Looking into this further, you may find this worth a read:-

https://linux.die.net/man/7/symlink

.....or you can access it via

Code: Select all

man 7 symlink

...in the terminal (opens with your default browser).

Other reading suggests that, although in theory Linux will traverse any number of sym-links till it finds a "real" file, in practice it seems the kernel may impose a limit as to how far a chain of sym-linked commands can actually travel before it 'fails'. Don't forget, every dependency 'soname' - the .so link - is always a link to the actual library itself (this allows for updating a library without upsetting the $PATH an application is trying to follow).

I've had trails of sym-links - one sym-link pointing to another, which then points to yet another, etc - go as far as four 'sequences' before failing to find the 'dereferenced' target. Apparently, in practice a 'hard' link will sometimes be more appropriate ( this uses 'ln' by itself without the '-s' option).

https://www.geeksforgeeks.org/soft-hard ... unixlinux/

The 'takeaway' here is that a sym-link is a string referencing a $PATH to the file(s) in question. You've probably noticed yourself that if the 'target' of a sym-link is moved, you end up with that 'dangling link' - the warning triangle icon. However, with a 'hard' link, the string references the inode of the target files/directory directly.....so will 'follow' it around the file-system even if it gets moved, as long as the target's name remains the same. This is because the 'inode table' is part of the file-system's overall 'metadata', cataloguing every single item's location within that file-system.

Just thought the above web-links might shed a bit of light on some of the 'peculiarities' inherent with using sym-links. It may help, it may not.

Mike.

[geo_c]

https://www.geeksforgeeks.org/soft-hard ... unixlinux/

However, with a 'hard' link, the string references the inode of the target files/directory directly.....so will 'follow' it around the file-system even if it gets moved, as long as the target's name remains the same. This is because the 'inode table' is part of the file-system's overall 'metadata', cataloguing every single item's location within that file-system.

Well this is what I always thought about hard links. But this geeks article seems to contradict the idea that changing the name breaks the link.

• Even if we change the filename of the original file then also the hard links properly work.

• We cannot create a hard link for a directory to avoid recursive loops.

• If original file is removed then the link will still show the content of the file.

• The size of any of the hard link file is same as the original file and if we change the content in any of the hard links then size of all hard link files are updated.

So the way they make it sound, it's more like the links are mirrors of the original file. They are also saying that if you delete any of the hard links or the original, all the other links still contain the file.

[williams2]

With hard links, there is 1 file
with more than 1 file name.

There are no mirrors or copies, just 1 file.

You can't give the file a name that would put it in a different device.
for example, if you have a file in /root/, you can't make a hard link (a new file name in addition to the original file name) in /mnt/home/

A symbolic symlink CAN point to another file system on another device.

If you create a file and name it a
and make 2 hard links b and c
changes made to the 1 file can be done using any of the 3 file names.
File b is the same file as file a and
file c is the same file as file a

To delete the file you need to delete all 3 file names.

[geo_c]

With hard links, there is 1 file
with more than 1 file name.

To delete the file you need to delete all 3 file names.

Yes, you put it way more simply. That clears it up for me.

So hardlinks may be a better option in some cases. Most links I use are symbolic links due to the fact I'm linking across filesystems. eg. from /mnt/home > /root

Hard links would probably be better in cases inside /root or top level where one would want to be able to delete a file in one location (hard-link) but always be sure links in certain other locations aren't affected.