fix #117 by changing move operations

[salbeira]

Changes renameFile of temporary files to a copyFile tmp path, followed by a removeFile tmp. This now allows "moving" files across device borders as renameFile tends to fail when used with something like a tmpfs or simply having your working directory on a different mount than the /tmp/ directory. renameFile currently fails when decker tries to move generated files from the tmp directory to the workspace.

Here the documentation of renameFile:

renameFile old new changes the name of an existing file system object from old to new. If the new object already exists, it is replaced by the old object. Neither path may refer to an existing directory.

A conformant implementation need not support renaming files in all situations (e.g. renaming across different physical devices), but the constraints must be documented. On Windows, this does not support renaming across different physical devices; if you are looking to do so, consider using copyFileWithMetadata and removeFile.

@flipreverse can confirm that this fixes this issue on his end

@monofon @mbotsch Can you two check if this creates any conflict inside your current workflow?

[monofon]

No problems with this fix here. Should be working.

Vsode counts 10 occurrences of this tmp file rename pattern in the code base. This patch only changes 5 of them. Why not change them all? And,while you're at it, make this fix a function (like safeRenameFile or something).

[salbeira]

(was on vacation)

Aren't the other instances of renameFile moves inside the project directory itself (like renaming the -recording.webm to -recording-0.webm etc. ?) I guess you know way better where moves from tmp into the project root happen. Where would we put the "saveRenameFile" function? Do we have some "util.hs" file where we put these small and simple functions?

saveRenameFile:: FilePath -> FilePath -> IO ()
saveRenameFile tmp dst = do
    copyFileWithMetadata tmp dst
    removeFile tmp

Also when I search through ./src in VS Code I can only find 4 more occurrences: One in your "unused" writeToMarkdowNFile writeback code, and 3 in the afforementioned "appendVideoUpload" that should be happening inside the project directory anyway.