Summary

file-copy does not what I'd think when used on directories

Metadata

Description

Currently, file-copy used on a directory will create an empty regular file. It is certainly true that one should not expect it to work on directories but I think signalling an error or returning #f when doing so would be more sensible than the current behavior.

Changes and comments

[2010-08-24 12:08:28 UTC] felix changed priority from not urgent at all to minor

[2010-08-24 12:08:28 UTC] felix changed status from new to assigned

[2010-08-24 12:08:28 UTC] felix set owner to felix

[2010-08-24 12:08:28 UTC] felix changed milestone from 4.6.0 to 4.7.0

[2010-08-24 14:27:59 UTC] felix changed status from assigned to closed

[2010-08-24 14:27:59 UTC] felix set resolution to fixed

[2010-08-24 14:27:59 UTC] felix wrote:

`file-copy` and `file-move` signal an error if used on a directory, now. See "experimental" branch.

[2010-08-24 14:41:36 UTC] sjamaan wrote:

Didn't file-move do the right thing when used on directories? It'd be a shame if that worked before but now throws an error. I don't know how it works on Windows, but in Unix moving is renaming. Or do we have a separate procedure for that?

[2010-08-24 15:55:00 UTC] felix wrote:

Replying to sjamaan: > Didn't file-move do the right thing when used on directories? It'd be a shame if that worked before but now throws an error. I don't know how it works on Windows, but in Unix moving is renaming. Or do we have a separate procedure for that?

`file-copy` and `file-move` only copy/move files by manually reading writing blocks of data. Mostly useless.

`rename-file` (library unit) does a proper `rename(2)` system call.

[2011-06-01 09:00:41 UTC] felix changed milestone from 4.7.0 to 4.8.0

[2011-06-01 09:00:41 UTC] felix wrote:

Milestone 4.7.0 deleted

[2012-09-24 21:47:48 UTC] felix changed milestone from 4.8.0 to 4.9.0

[2012-09-24 21:47:48 UTC] felix wrote:

Milestone 4.8.0 deleted