Change definition for the target option of p:file-copy

[xatapult]

The spec of p:file-copy now says:

If the target is a directory, the step attempts to copy the file or directory into that directory, preserving its base name.

This is now interpreted (by Morgana) (and I do think that's correct) that the specified directory must exist on disk. But this also means that a copy operation like:

<p:file-copy href="x.xml" target="build/"/>

will create a file called build and not a file build/x.xml, even though the value of the target option tries to specify a directory (because it ends with a /).

I think this rather counter-intuitive and we should change the definition (so the above copy does create build/x.xml).

[ndw]

Seems reasonable to me, although I worry that it's a little but subtle.

[ndw]

Presumably this also applies to p:file-move?

[gimsieke]

I think we discussed this in London in 2019 although I don’t see it in the minutes.

IIRC we aimed at mimicking cp’s behavior, which is to complain if the target is identified as a directory by means of its trailing slash and if this directory doesn’t exist.

If this is our guidance, <p:file-copy href="x.xml" target="build/"/> should fail if there is no directory named 'build'.

[ndw]

Conceptually, I like the idea of failing if the directory doesn't exist.

But I wonder if creating it would be more consistent. My thinking is that

  <xsl:result-document href="build/x.xml"/>

Will create the directory. And (I believe) so will <p:store href="build/x.xml"/>.

That doesn't really address my concerns about the subtlety, but since almost everything about URIs is subtle if you look closely enough, perhaps I should just let go.

If we made a decision to change the behavior in 2019 but forgot to implement it, does that give us license to reconsider the behavior in 3.1? We haven't actually shipped a "community report" version of 3.1 yet and the file steps were not officially in 3.0.

[xatapult]

I don't think we should change this now. Too many incompatibility issues.

Anyway, my idea of how this should work: Going from the (usally partial) URIs in the href and target options to the final full URIs of what should be copied can be done just doing string handling. Don't look at what exists on disk or not. Take the final string values and then do what is necessary/specified.

There is another issue (by me) about p:file-copy: #38

[ndw]

There aren't going to be fewer incompatiblity issues if we wait! In fact, after we've published "final" specifications for the file steps, I don't think it will be possible to change the semantics of p:file-copy (or p:file-move) without adding a new attribute or something to request the alternate behavior.