Jim Meyering wrote: > Eric Blake wrote: >> According to Pádraig Brady on 10/5/2009 3:53 PM: >>>>>> This is a new test, but FC5 is soooo old, >>>>>> that I'm not sure it's worth worrying about. >>>>> March 2006? >>>> The failure is probably a function of the kernel. >>>> Which is it? >>> In summary this is what fails: >>> >>> $ touch a >>> $ ln -s a symlink >>> $ ln -L symlink hardlink >>> ln: creating hard link `hardlink' => `symlink': Invalid argument >>> >>> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18 >>> and my FC5 system is 2.6.17 >> This should fix it. I don't have access to FC5, but I tested the new code >> path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure) >> along with a temporary setting of have_follow_really=-1 in linkat.c. I >> also verified that the replacement is not picked up on cygwin 1.7, where >> AT_SYMLINK_FOLLOW was implemented at the same time as linkat. >> >> The patch copies from areadlink.c, as well as link_follow earlier in >> linkat.c, to create two new fd-relative helpers. For now, I didn't see >> any reason to expose them, but areadlinkat may someday be worth making >> into a full-blown module. > > Wow, that was quick. Thanks. > I should have read this first. > > I was just reviewing the changes in gnulib and > see a few that should be included in the imminent coreutils > beta release, so will probably take this one, too.
Needs a couple of tweaks.. This needs to be added to linkat.c (seems like it should be refactored somewhere?) #ifndef SIZE_MAX # define SIZE_MAX ((size_t) -1) #endif #ifndef SSIZE_MAX # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2)) #endif Also a minor nit in s/Linux/Gnu\/Linux/ After that the test passes. cheers, Pádraig.