On 05.01.14 John O'Hagan (m...@johnohagan.com) wrote: > On Sat, 4 Jan 2014 23:32:22 +0100 > Hilmar Preusse <hill...@web.de> wrote:
Hi, > > Hm, I wouldn't expect hard links at that location, but I don't know > > enough about ucf to evaluate. Did you experience system crashes on > > that box recently (i.e. in June and November), which could have led > > to a corrupted file system? > > A couple of weeks ago I ran a utility called rdfind to replace > identical files with hard links to save space on this laptop, so I > guess most likely this is an unintended side-effect of that. > This is most likely the root cause: ucf can't handle the situation. I wouldn't call it a bug but rather a missing feature. My suggestion would be to remove the hard links and replace them by file copies. The i-node id's gives the information, which file was a copy of which one. > I update my system frequently and AFAIK this is the only time a > package has cared about this so far. > Not sure how many packages use ucf these days. If you look into the hashfile you'll see the config files under ucf control. This gives a pointer to the packages, which /could/ be affected. > If on the other hand it is a result of corruption as you suggest, that > is also possible, because every now and then my laptop runs out of power > without suspending or shutting down as it is supposed to do (due to the > slight flakiness of laptop power management). > Well, I think the replacement of copies by hard links is the real root cause. Most modern file systems should be crash proof. H. -- sigmentation fault
signature.asc
Description: Digital signature
