Re: fix for rename function on Mingw

2009-03-21 Thread Michel Boaventura
Hello Ben, >> How does MoveFileEx with MOVEFILE_REPLACE_EXISTING behave when >> the destination file exists and is a hard link [1] to another file? Will >> the other file see some changes? I.e. will the hard linked file be >> overwritten, or will the hard link be broken (as on POSIX systems)? > >

Re: coreutils 7.1.49-ebb9 FTB sparc/Solaris, AIX

2009-03-21 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 3/20/2009 6:30 AM: >> $ find /usr/include | xargs grep sig_atomic_t >> /usr/include/sys/signal.h:typedef volatile int sig_atomic_t; > > Therefore, 'volatile sig_atomic_t' is not a bug, even if sig_atomic_t > already included

Re: fix for rename function on Mingw

2009-03-21 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 3/21/2009 6:03 PM: >> On Windows there is no link as on linux. The link file on windows is >> just a regular file with >> the address of the original on it. So I don't know how to test it on windows. > > Windows does support

Re: fix for rename function on Mingw

2009-03-21 Thread Ben Pfaff
>> Bruno Haible writes: >>> How does MoveFileEx with MOVEFILE_REPLACE_EXISTING behave when >>> the destination file exists and is a hard link [1] to another file? Will >>> the other file see some changes? I.e. will the hard linked file be >>> overwritten, or will the hard link be broken (as on POSI

Re: Serial number formats

2009-03-21 Thread Ralf Wildenhues
* Bruno Haible wrote on Fri, Mar 20, 2009 at 12:49:19PM CET: > Ralf Wildenhues asked: > > What exactly is the point of using a different format and extraction > > code than aclocal does? ... > > Gettext is using a format slightly incompatible to the aclocal one here, > > aclocal exploits '# serial

Re: fix for rename function on Mingw

2009-03-21 Thread Ben Pfaff
Bruno Haible writes: > How does MoveFileEx with MOVEFILE_REPLACE_EXISTING behave when > the destination file exists and is a hard link [1] to another file? Will > the other file see some changes? I.e. will the hard linked file be > overwritten, or will the hard link be broken (as on POSIX systems

Re: fix for rename function on Mingw

2009-03-21 Thread Ben Pfaff
Jim Meyering writes: > That looks fine. > Please increment the serial number in rename.m4. > Also, you'll want to remove the trailing blanks on two lines: s/fi $//. Thanks for pointing out those problems. I've fixed them in my local copy. I'm going to wait to push anything until I get Bruno's

Gnulib and pspdev

2009-03-21 Thread Sylvain Beucler
Hi, I'm working on a cross-build of GNU FreeDink to make it run on Sony PlayStation Portable. The build is based on a slightly modified gcc cross-compiler for mipsel, and a minimal libc on top off of newlib (ftp://sources.redhat.com/pub/newlib/) - check 'psptoolchain' and 'pspsdk' at http://svn.p

Re: fix for rename function on Mingw

2009-03-21 Thread Jim Meyering
Ben Pfaff wrote: > On the Windows platform, Microsoft documents the rename function > as refusing to replace existing destination files. This is > allowed by C89 (and C99) but it is not POSIX-compliant, and it > can be quite surprising to programs that want to atomically > replace files. > > Here