On Mon, Feb 02, 2026 at 09:46:04AM -0800, Paul Eggert wrote: > On 2026-02-02 07:06, Pavel Cahyna wrote: > > On Fri, Jan 30, 2026 at 12:58:28PM -0800, Paul Eggert wrote: > > > I am leery of mkdir -p semantics in general, as it has too many > > > issues (what permissions should the intermediate directories use?). > > > > Could they use the same permissions as the last one? > > Well, retreating a bit, I suppose we could do the same thing that we already > do with long file names none of whose components already exist.
Yeah, I started working on it but has not been able to get it entirely right yet. The basic idea is to use a reduced version of extract_dir() (would behave like extract_dir() with keep_directory_symlink_option set and old_files_option == NO_OVERWRITE_DIR_OLD_FILES and mode set according to newdir_umask). The intermediate directories would then be created by maybe_recoverable(). > > > > > 4. We do (2) and (3) lazily, i.e., only when we need FOO/DIR (or DIR) > > > > > open > > > > > to extract a file underneath it. > > > > > > > > Is it necessary? I would assume that it is simpler to do it > > > > unconditionally at the beginning, and that we need it almost always > > > > anyway. > > > > > > I am worried about combinations like '-C a -C b file', where we should > > > create b/DIR (for b/DIR/file) but need not create a/DIR. > > > > Hmm. Is there a a way to know which -C before the extraction starts is > > the last one? (Or, when we have processed the last -C before the > > extraction starts? And do (2) and (3) at this moment?) > > Yes, that's what I meant by "lazily". The idea is to do what 'tar' does now, > and one must be lazy to do that. OK > > https://github.com/skupperproject/skupper-router/commit/6a9f03f590a1ab44e106b3af63a9fa0f0fbdef30 > > They remarked that according to a search on GitHub (I had not thought > > of that) they are hardly alone. When I search on GitHub for > > "--one-top-level", most of the uses are with a relative path, but I saw > > some cases with an absolute path. > > I suppose we need to support that, then. But how does --one-top-level > interact with -P? Without -P, shouldn't --one-top-level=/a/b/c be equivalent > to --one-top-level=a/b/c? (This whole thing is confusing, if you ask me, and > we need to be clear in the documentation about the confusion.) The two options are incompatible already, tar.c: if (absolute_names_option) { struct option_locus *one_top_level_loc = optloc_lookup (OC_ONE_TOP_LEVEL); struct option_locus *absolute_names_loc = optloc_lookup (OC_ABSOLUTE_NAMES); if (optloc_eq (one_top_level_loc, absolute_names_loc)) option_conflict_error ("--one-top-level", "--absolute-names"); ... I guess it is because in the current implementation --one-top-level=/a/b/c has a bit of overlap with -P (uses absolute paths). In the new implementation it would work more like -C, but -C /a/b/c also does not translate to -C a/b/c. Or perhaps I misunderstood? > > > +If multiple @option{-C} options are present, > > > +each has its own subdirectory with the same name. > > > > What does this mean? I tried mkdir -p a/b; tar -C a -C b > > --one-top-level=foo -xf ...tgz > > and it did not create a/foo and a/b/foo, just a/b/foo. > > Something like this: > > tar --one-top-level=foo -C a xxx -C b yyy -xf tarball > > This extracts a/foo/xxx and a/b/foo/yyy. I see. What about changing the description to something like: "If multiple @option{-C} options are present, each one causes extraction to happen into its own subdirectory with the same name." > > Note the "When this option is used during archive creation" - this seems > > to imply that you should not use -C in the middle of arguments during > > extraction to change directory after some files are extracted, although > > in practice this works (is it the same case like --one-top-level with an > > absolute path?) > > It's long been the case that -C a -C b is equivalent to -C a/b, and that if > there's something between the -C options it's extracted into a. Sure, I understood that, but it is interesting that it has been undocumented until now. I understand it needs to be kept as it is anyway, just as with absolute paths as arguments to --one-top-level (and it has been the case probably for much longer). Btw. the original bug report references Hyrum's law (Wikipedia states it as "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.") Regards, Pavel
