Package: xorriso
Version: 1.5.4-4
Control: found -1 1.5.0-1
Control: found -1 1.5.2-1
When -clone is used on a file that belongs to the loaded
session, its contents get /copied/ to the new one (with the
location of the original one updated to match the copy);
while when used on a file /within/ the current session, the
resulting file (as expected) appears to share the extent
with the original one.
I believe that when it comes to rearranging data on ECMA 119
filesystems, it is as important for -clone /not/ to copy the
affected files’ contents as it is for, say, -move.
Consider, for instance, the following shell code.
#!/bin/sh
set -e
set -x
set -C -u
## NB: an arbitrary value, but must be larger than first session size
session_offset=256
f=$(mktemp -- /tmp/hello.XXXXX)
printf %s\\n "Hello, world!" >| "$f"
g=$(mktemp -- /tmp/iso.XXXXX)
xorriso -padding 0 -uid 0 -gid 0 \
-outdev stdio:/dev/fd/5 5>| "$g" \
-pathspecs on -add /hello/hello.world="$f" -- \
-clone /hello/hello.world /hello/hello.withn
h=$(mktemp -- /tmp/iso.XXXXX)
xorriso -padding 0 -uid 0 -gid 0 \
-indev stdio:/dev/fd/4 4< "$g" \
-grow-blindly "$session_offset" \
-outdev stdio:/dev/fd/5 5>| "$h" \
-clone /hello/hello.world /hello/hello.clone
dd bs=2048 seek="$session_offset" conv=notrunc of="$g" < "$h"
isoinfo -l -i /dev/stdin < "$g"
isoinfo -l -T "$session_offset" -i /dev/stdin < "$g"
The resulting sessions are as follows.
+ isoinfo -l -i /dev/stdin
Directory listing of /
d--------- 0 0 0 2048 Oct 26 2022 [ 18 02] .
d--------- 0 0 0 2048 Oct 26 2022 [ 18 02] ..
d--------- 0 0 0 2048 Oct 26 2022 [ 20 02] HELLO
Directory listing of /HELLO/
d--------- 0 0 0 2048 Oct 26 2022 [ 20 02] .
d--------- 0 0 0 2048 Oct 26 2022 [ 18 02] ..
---------- 0 0 0 14 Oct 26 2022 [ 33 00]
HELLO.WITHN;1
---------- 0 0 0 14 Oct 26 2022 [ 33 00]
HELLO.WORLD;1
+ isoinfo -l -T 256 -i /dev/stdin
Directory listing of /
d--------- 0 0 0 2048 Oct 26 2022 [ 274 02] .
d--------- 0 0 0 2048 Oct 26 2022 [ 274 02] ..
d--------- 0 0 0 2048 Oct 26 2022 [ 276 02] HELLO
Directory listing of /HELLO/
d--------- 0 0 0 2048 Oct 26 2022 [ 276 02] .
d--------- 0 0 0 2048 Oct 26 2022 [ 274 02] ..
---------- 0 0 0 14 Oct 26 2022 [ 280 00]
HELLO.CLONE;1
---------- 0 0 0 14 Oct 26 2022 [ 280 00]
HELLO.WITHN;1
---------- 0 0 0 14 Oct 26 2022 [ 280 00]
HELLO.WORLD;1
Note that all three entries moved from LBA 33 to LBA 280.
Using two months old versions from Git (libburn 19545142,
libisoburn 3318fa47 and libisofs c6cb7dfa; the few changes
since these revisions made to the latter two don’t seem to
be relevant to the issue) gives the same result.
Omitting the -grow-blindly option (and using -dev stdio:"$h"
instead) doesn’t seem to change this behavior, either.
--
FSF associate member #7257 http://am-1.org/~ivan/
