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

[Pádraig Brady]

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.

cheers,
Pádraig.