Eric Blake wrote: > According to Jim Meyering on 9/25/2009 5:59 AM: >> When I see the tentacles of this change reaching so deeply into the core >> of gnulib and coreutils, I have to question whether it is worthwhile >> to accommodate mingw's lack of inode numbers. >> >> Opinions? > > Raise this issue to the mingw list, and see if they can start populating > st_ino in the same way that cygwin does?
That sounds like the best approach. If someone is interested enough to pursue it. > Write a gnulib module that fixes > mingw [f]stat to populate a reasonable st_ino? Inode numbers really are > core to a number of Unix programs, and their absence on mingw is a huge > portability sticking point. I still plan on respinning this patch to at > least solve some of the easier issues (such as getting the linkat() unit > test to pass successfully), but I'm starting to thing that porting > same_name to mingw is a lost cause unless someone else steps in and helps > write the patches. Supporting mingw is good from portability and exposure standpoints, but when accommodating a fundamental lack like this puts a serious dent in maintainability, efficiency or even "mere" aesthetics of the code, then we have to draw the line.
