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)?
>
>
-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
-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
>> 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
* 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
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
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
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
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