What does p:file-copy do with special files?

[ndw]

What should p:file-copy do with symbolic links, block devices, character devices, etc.?

Is that implementation defined?

Do we expect <p:file-copy href="/dev" target="/tmp/dev"/> to succeed on a Unix box?

Symbolic links are both the more likely problem and the more complicated one. Given:

/tmp/x/copytest/a/fail -> /path/to/nowhere
/tmp/x/copytest/a/file
/tmp/x/copytest/b/a -> ../a
/tmp/x/copytest/b/up -> ../..

What is <p:file-copy href="/tmp/x/copytest" target="/tmp/x/result"/> supposed to produce, assuming /tmp/x/result does not exist before the operation begins?

(Extra credit: consider how this should work on Windows boxes with the various NTFS filesystem features.)

[ndw]

I wonder if the following is sufficient.

1. If a symbolic link is to an absolute location or a location that does not exist, recreate that symbolic link
2. If a symbolic link is to a relative location within the structure being copied, recreate it within that structure
3. If a symbolic link is to a relative location outside the structure being copied, create an absolute symbolic link to that location
4. Ignore special files

[gimsieke]

For symbolic links it’s maybe sufficient to have a boolean option dereference-links. If it is false(), symbolic links will be kept as they are (verbatim, that is, a relative link will remain the same relative link, an absolute link will remain the same absolute link), no matter whether they pointed anywhere or not, no matter whether the target link points anywhere or not.

If true(), symlinks will be followed and the files/directories they point to will be copied. Processors should report loops as errors when copying with dereferencing on.

If a symlink is dangling and dereference-links is true, it’s an error that can be ignored with fail-on-error="false". In this case, the dangling link won’t be kept as a symlink either, it will rather be missing in the destination.

Hard links: Files they point to will be treated as regular files, as if there were no hard link. I’m not sure whether hard links for other items (directories, block devices, etc.) exist, but I think they should be treated as the items they point to.

Special files (devices etc.): implementation-defined

[ndw]

I don't think hard links are an issue. Those are implemented (at least in Unix) by having different directory entries point to the same inode on disk. I think there's a reference count, but I don't believe there's anything about one entry that can lead you to the other. (Short of reading the whole disk, naturally.)

I suppose we could add a dereference links option. Defaults to...true?

[ndw]

Curiously, a naive application of cp -r with symbolic links that form a loop just blows up...

I'm not recommending that behavior, I'm just saying it's curious.