Hello, On Mon, Feb 16, 2026 at 08:37:27PM +0100, Pavel Cahyna wrote: > thank you for all your advice. I made a fix that allows absolute > paths to --one-top-level again and confines extraction to the > --one-top-level directory (instead of to the current or -C directory). > > The patch leverages the existing -C code. In order to do that, every > entry in the wd[] table gets another companion entry in the table that > represents the --one-top-level directory. There is one additional field > in each entry that allows skipping the companion entries if they are not > desired. > > The actual directory is created lazily by chdir_do() if needed, as you > requested, to avoid empty "a/foo" after --one-top-level=foo -C a -C b. > > The patch "by the way" fixes also extraction of hardlinks with > --one-top-level which currently is broken in the typical case (the > transform is not applied to the target, so the hardlink is wrong).
What do you think about the patch that I sent? I would like to progress on the issue, but I would need to know whether this direction makes sense. Best regards, Pavel > The patch does not yet handle the --show-transformed case with > --one-top-level that you discussed in another subthread. As a result, two > tests now fail (onetop02.at and onetop04.at). I suppose that this would > be quite easy to fix. > > Another issue that I am aware of is that I am not sure whether to call > repair_delayed_set_stat and/or delay_set_stat on the newly created > directories like extract_dir() does (the whole delay_set code is abit > mysterious to me). > > Use of --create together with --one-top-level should probably be > forbidden, as unlink.c uses wd[] in a way that will likely break in the > presence of companion entries (the chdir_do call in > flush_deferred_unlinks). > > Other than that, I believe that the patch is fairly complete, although > of course it needs to be better commented and documentation updated. > Please have a look.
