Confusing error reply by iso_tree_add_node(), inability to graft in what i want

[scdbackup]

When i add a node refering to a disk file with the same leafname as an existing node in the same directory, then this fails with ISO_NODE_NAME_NOT_UNIQUE.

Understandable, as by default the new node would get the same name as the existing one.

But that is not my intention. I just do not have a chance to tell libisofs the intended Rock Ridge name before i create the node from the disk object. Only afterwards i can set the intended name, which i checked before that it does not exist yet in the directory.

This leads to two application programmer complaints:

- the return value of iso_tree_add_node() is very confusing, especially if i just removed the old node with the _intended_ name (not the one with the disk leafname).

- since there seems to be no way to set the Rock Ridge name before creating the node, i am effectively unable to map a disk file into an ISO directory if that directory happens to contain that file's leafname as RR name. Although i did not indicate in any way that i want the new node to have the same name.

---

Remedy proposals:

1) In iso_tree_add_node() give the new node some unique default name rather than to return error.

2) Introduce new API call which allows to create a IsoFile with an explicit RR leafname independent of the disk path. Deprecate iso_tree_add_node(). This call should return error if the RR leafname already exists.

[scdbackup]

Maybe an example is needed:

This fails:

xorriso ... -add /a=/home/thomas/x /b=/home/otherguy/a

because /a is already there when the IsoNode representing /home/otherguy/a shall be created and later be renamed to "b".

[vreixo]

It is not a bug, it is a missing feature. iso_tree_add_node() does what it must do, add a node to a dir, with same name and attributes of IsoFileSource? they come from.

What we are missing is the corresponding iso_tree_new_node(parent, name, IsoFileSource?), in the same way we have iso_tree_add_new_dir, iso_tree_add_new_symlink(), ...

Note that we will also add

iso_tree_add_new_file(IsoDir *parent, const char *name, stream, file)

[scdbackup]

What we are missing now is a way to fulfill this grafting sequence

/a=x /b=a

Thus i deem it a bug which keeps me from doing what is quite natural.

What we are missing is a IsoFile and an IsoNode counterpart to the add_new_*() functions which exist in the API. They all get a parameter "name".

How would i obtain an IsoFileSource? from a local disk file path, btw ?

---

Application level workaround:

Have an empty ISO directory "/xorriso_works_around_what_is_not_a_bug".

Create each node there.

Set its leafname.

Move it to target.

[vreixo]

How would i obtain an IsoFileSource?? from a local disk file path, btw

mmm, IsoFilesystem? to local filesystem is still not exposed. It can be done easily, but for now I will instead use a char* parameter to iso_tree_new_node(), meaning the path of the file. Addtion of nodes vis IsoFilesystem? will the postponed until IsoBuilders? were exposed, maybe next release.

[vreixo]

Function iso_tree_add_new_node(), added to my branch (rev 383) should allow what you want. Please test it, I had not enought time to do so.

[scdbackup]

iso_tree_add_new_node() seems to work properly.