copy-file and move-file do not preserve permissions

[alicemaz]

both procedures create a new output file using open, so permissions are always (assuming normal umask) 644. this patch sets the permissions to those of the input file after writing all bytes and before closing the ports. tested on PLATFORM=linux. I do not know the implications of this on windows; the fact that C_chmod and C_fchmod have definitions in posixwin.scm makes me assume this is safe, but I cannot be sure without a machine to test on

[evhan]

This behaviour would be ideal, but we want to avoid introducing a dependency from file to file.posix -- those libraries are currently totally distinct, neither depends on the other.

I don't see an obvious way to do the same without the dependency apart from just pulling the code we need into file.scm (and potentially #ifdeffing it as necessary). This might not be too bad, though -- we do it for symbolic-link?, for example, and all we really need in there is chmod(2) and stat(2).

[alicemaz]

that makes sense. though my next question is, if inlining posix functionality and ifdefing it out for windows is prefereable to using chicken's existing posix interface, is there any reason not to replace the move-file function with rename(2)? again I have no idea how this works on windows, but on linux moving a file should be basically cost-free

[evhan]

It's supposed to match the behaviour of copy-file, which actually copies a file (as in, block-by-block). rename(2) has different semantics, for example when it comes to cross-filesystem operations. rename(2) is what you get with rename-file from the chicken.file module, which like you say offers the cost-free option.

#;1> (import (chicken file))
#;2> (rename-file "/mnt/foo.txt" "/tmp/foo.txt")

Error: (rename-file) cannot rename file - Invalid cross-device link
"/mnt/foo.txt"
"/tmp/foo.txt"

        Call history:

        <syntax>          (rename-file "/mnt/foo.txt" "/tmp/foo.txt")
        <eval>            (rename-file "/mnt/foo.txt" "/tmp/foo.txt")   <--