On 1/5/20, to...@tuxteam.de <to...@tuxteam.de> wrote: > On Sun, Jan 05, 2020 at 10:47:52AM +0100, Pascal Hambourg wrote: >> Le 04/01/2020 à 20:47, Sven Joachim a écrit : > > [FAT, hard links] > >> >a feature that is crucial for dpkg. >> >> I vaguely remember this, but not when and why dpkg needs to create >> additional hard links. Can you refresh my memories ? > > My search engine is lucky today (no, Goog, no cookies for you today ;-) > > > https://unix.stackexchange.com/questions/208073/dpkg-replacing-files-on-a-fat-filesystem > > I'd be more worried about whatever packagers do in their post-install > scripts. After all, hard links are pretty handy when trying to do > atomic operations on file systems. If there's no policy explicitly > banning hard links, I'd expect them to be used...
DISCLAIMER: HOPEFULLY I'm understanding the use of "hard links" here such as has been my understanding of that topic for *many* years.. :) For the most part, I thought about the only problem with hard links was that whatever was using them had to exit an entire hierarchy to then dig back in from the top to find its target. That comes from my earliest days of creating anchor links in web design where you're trying to help your webpages load as fast as possible for the end user. As I was sitting pondering this, two thoughts keep floating in my head... 1) Maybe this, primarily the "fat" part of it, somehow explains why rsync flat out refused to copy a limited number of files over to a USB for me a few ago. Happened a couple times in different situations. I can't remember how to recreate it to say yay or nay on it having been about this topic. 2) A couple years ago, my linux-image installations on debootstraps were creating "hard" /vmlinuz and /initrd.img links. At some point in my decades' old perennial newbie-ness, I accidentally stumbled on a usage case where that very detrimentally.... linked out of my chroot somehow... and was targeting my host's /boot directory, i.e. NOT the intended /mnt/deboostrap/boot directory which it SHOULD have been seeking, instead............... To this day to fix it, one of my early-on debootstrap checklist points is to consciously verify that /vmlinuz and /initrd.img symlinks are being used instead of hard links immediately after apt/apt-get is finished installing linux-image. Apparently a Developer at some point noticed the same on some level because I haven't had to create new links there in a LONG time now. In wondering how I would have caught that major whoa, maybe it was that the hard link was reflecting the different kernel version. That sounds like the most likely way a User would catch that kind of [anomaly]. Maybe.... "fat" is trying to (intelligently, proactively) protect us from the rare occasion something like my experience might occur?? Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with... a... seriously... more backup modems... NOW. Because weather-util says another thunderstorm is in the queue this week..... *
