2

There are many Unix commands that will fail unless some subdirectory already exists, even though it would be a trivial matter for such commands to go ahead and create the missing subdirectory before proceeding.

For example, for touch:

% touch /tmp/foo/bar/baz/frobozz
touch: cannot touch `/tmp/foo/bar/baz': No such file or directory
% mkdir -p /tmp/foo/bar/baz
% touch /tmp/foo/bar/baz/frobozz # succeeds

Similarly, for mv:

% mv --target-directory=/tmp/foo/frotz/quux /tmp/foo/bar/frobozz
% mv: failed to access `/tmp/foo/frotz/quux': No such file or directory
% mkdir -p /tmp/foo/frotz/quux
% mv --target-directory=/tmp/foo/frotz/quux /tmp/foo/bar/frobozz # succeeds

One notable exception to this behavior is mkdir itself, whose -p flag tells it to "create subdirectories as needed".

I am a bit puzzled by the fact that touch, mv, et al. won't do the "obvious thing", either by default, or upon request via some flag (such as mkdir's -p).

I figure there must be a very good reason for this, but it's not obvious to me. Insights welcome.

(The motivation for asking this is that I'd like to implement a utility that is pretty much like the (nonstandard) mmv utility, except that, contrary to the real mmv, it would "create subdirectories as needed", and I'm wondering if this new feature would be A Really Bad Idea.

For example, with the utility I'm thinking of—let me call it mmmv— one would be able to simultaneously move and rename the files

1caf73ee55b4e11d6e3b12ccbf8c477c2839bfae
1f37fd8ce865f98579d10d8045ac1e88c6717215
73f2af84ba8ed27fa332d52745274377aa67cda5
a257a7c7cac26c391e8636193ff47b45c5e587ec

to

1c/af73ee55b4e11d6e3b12ccbf8c477c2839bfae
1f/37fd8ce865f98579d10d8045ac1e88c6717215
a2/57a7c7cac26c391e8636193ff47b45c5e587ec
73/f2af84ba8ed27fa332d52745274377aa67cda5

with a single command, like this:

% mmmv '??*' '#1#2/#3'

For this to be possible mmmv needs to be able to create the two-letter-named subdirectories as needed.)

1

Generally the reason utilities don't do this is because it's not expected, and there can be security implications of doing so.

For example, lets say you have a directory which is supposed to be private, /foo, with mode 700 (rwx------). If you do touch /foo/bar and /foo doesn't exist, it would create it, potentially with a default of 755 (rwxr-xr-x). But /foo was supposed to be private, and whatever normally creates /foo and makes it private won't do so. And since you're unaware that /foo was just created, you don't know that you need to go and adjust it.

  • 1
    mkdir -p, tough, simply creates the directories using you umask settings. If the foo dir has no "x" flag for other users, the underlying directories are still protected, no? Only the owner will be able to cross foo and going down. – Rmano May 5 '14 at 16:57
  • 1
    @Rmano yes, but it is the expected behavior of mkdir -p to do so. mkdir without the -p will not do this. I would think the automatic creation behavior be acceptable with utilities such as touch if they also had an option like -p, but it shouldn't be default. You can set umask to help with this behavior yes, but that will set the same permissions for all directories that get created, maybe they shouldn't be the same. But the answer is that it's all about expected behavior, and not doing things that aren't expected. – Patrick May 5 '14 at 18:25
  • I see. Definitely should not be the default behavior, I agree. – Rmano May 5 '14 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.