On 05/08/2013 01:53 PM, Rémy Lefevre wrote: > 2013/5/8 Pádraig Brady <[email protected] <mailto:[email protected]>> > > 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.
