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.
Regards, Rémy. 2013/5/8 Pádraig Brady <[email protected]> > 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. > >
