[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add --parents option to mv command in order to create parents direct

From: Rémy Lefevre
Subject: Re: Add --parents option to mv command in order to create parents directories
Date: Wed, 8 May 2013 16:06:00 +0200

Thanks for your explanation.

So I have to admit that my problem is confined to file system without hard link support. And I understand that this so uncommon situation doesn't need the implementation of a new feature.



2013/5/8 Pádraig Brady <address@hidden>
On 05/08/2013 01:53 PM, Rémy Lefevre wrote:
> 2013/5/8 Pádraig Brady <address@hidden <mailto:address@hidden>>
>     On 04/28/2013 05:55 PM, Rémy Lefevre wrote:
>     > Hello,
>     >
>     > mkdir and cp commands have the --parents option to create parents directories as needed. But this option is missing in mv. One has to create first the directory structure using mkdir --parents and then mv the file. This option is fine for simple moving command, but if one want to move files according to a pattern in a big tree structure, it starts to be too complicate as the directory name should be extracted for almost each moved file.
>     >
>     > So another solution is to use the cp --parents command and then delete the original files. But this solution is far from good for all the reasons that differentiate a copy from a move.
>     >
>     > So I propose to add a --parents option to mv command in order to create the parents directories as needed. In the case of acceptance, I could write a patch to add this feature.
>     Maybe, but I'm not sold on the need TBH.
>     At first glance it seems like it's uncommon enough
>     that using cp might suffice?  You could even do
>     this efficiently within a file system like:
>     { cp -l --parents src dst || cp --parents src dst } && rm -r src
> Alright. Using hard links is a good idea. I'm curious to know what the general difference between:
> "mv src dst" and "cp -l src dst && rm src"

Well link(2) might not be supported on the file system whereas rename(2) could be.
I.E. The above will be inefficient within a vfat file system for example.

Another attribute of the `cp -l;rm` approach, is that
it can allow you to keep a tree in a consistent state.
I.E. you can have the new location in place to switch to atomically,
before you delete the old location.

Other than that, the operations are similar.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]