[bug-patch] Bug: GNU patch 2.5.9 says "Invalid cross-device link" when disk is full

[Jamie Lokier]

This is a bug I just noticed in GNU patch 2.5.9, as distributed on
Ubuntu 9.04.

When doing a patch where the disk doesn't have enough space for the
new file, it stops with this error:

    patch: **** write error : Invalid cross-device link

That's quite confusing if you only have the one filesystem, and
doesn't really tell the user why it failed.

It should say something like this instead:

    patch: **** write error : No space left on device

The reason for the confusing message is shown in this trace:

    rename("/tmp/poOj4p93", "drivers/gpu/drm/drm_crtc.c") = -1 EXDEV (Invalid 
cross-device link)
    unlink("drivers/gpu/drm/drm_crtc.c")    = 0
    open("/tmp/poOj4p93", O_RDONLY|O_LARGEFILE) = 0
    open("drivers/gpu/drm/drm_crtc.c", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 
0100644) = 5
    read(0, "/*\n * Copyright (c) 2006-2008 Int"..., 16384) = 16384
    write(5, "/*\n * Copyright (c) 2006-2008 Int"..., 16384) = 16384
    read(0, "vice\n *\n * Called by a driver the"..., 16384) = 16384
    write(5, "vice\n *\n * Called by a driver the"..., 16384) = 16384
    read(0, " drm_crtc *crtc;\n\tstruct drm_mode"..., 16384) = 16384
    write(5, " drm_crtc *crtc;\n\tstruct drm_mode"..., 16384) = 8192
    write(2, "patch: **** write error"..., 23) = 23
    write(2, " : Invalid cross-device link\n"..., 29) = 29
    unlink("/tmp/poOj4p93")                 = 0

The rename from /tmp to the main filesystem returns EXDEV, which is
where the message comes from.  On my system it's because /tmp is a
different filesystem.

But all the patched files return EXDEV; it's not normally a problem.
Normally patch copies the file into place if the rename fails.

When the isn't enough space, the copy fails and patch reports the
error from rename(), instead of the error from write().

I notice that it aborts on a short write() result.  That's unwise.
Although POSIX requires full writes to regular files, I think some
network filesystems can return short write results if a signal is
received, even if the signal does not abort the program.  That's not
an error.  E.g. on Linux and perhaps some other OSes, NFS with the
"intr" mount option.

Continuing after short write() result also lets you get the reason for
the error.

So I think GNU patch should be changed to do this:

   - Don't abort on a short write() result.
     Keep trying to write the remainder.
   - When write() returns an error, report _that_ error.
   - Same for close() error, after writing.
   - Then it would never have reason to report the rename error.

Thanks,
-- Jamie