Ben Pfaff writes:
> Since this fixes all the objections that were posted in the first
> round, I'm going to push this as soon as I get confirmation from
> Michel that the updated commit works properly for him on PSPP
> (unless anyone raises a new objection in the meantime).
It took me a few days
Michael Haubenwallner writes:
> On Tue, 2009-04-07 at 20:23 -0700, 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
On Tue, 2009-04-07 at 20:23 -0700, 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 at
2009/4/8 Ben Pfaff :
> Michel, can you test that this works for you? Thanks!
It works! I just had to put "rename" on GNULIB_MODULES inside Smake,
as John told me.
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 is the second version of the g
Bruno Haible writes:
> Ben Pfaff wrote:
>> Here is a gnulib commit that I am proposing. It (cross)compiles
>> on Mingw, but I am waiting to hear back from my Windows tester to
>> find out whether it actually solves the problem for him.
>
> How does MoveFileEx with MOVEFILE_REPLACE_EXISTING behav
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 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 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
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
Ben Pfaff wrote:
> On the Windows platform, Microsoft documents the rename function
> as refusing to replace existing destination files. ...
>
> Here is a gnulib commit that I am proposing. It (cross)compiles
> on Mingw, but I am waiting to hear back from my Windows tester to
> find out whether i
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 is a gnulib commit that I am p
14 matches
Mail list logo
