bug#14628: mv command (and suggesting a feature for it)

[Pádraig Brady]

tag 14628 wishlist
stop

On 06/15/2013 09:02 PM, S. Dara wrote:
> Dear authors of the mv command,
> 
> With this email, I would like to suggest a feature for the mv command. I 
> believe this command should contain a safeguard feature which will deny 
> renaming a directory that contains files which are currently opened by the 
> user.
> 
> For example, I have a directory named 'my directory'. In this directory, 
> there is a .txt file which I had opened and was entering text in it. In the 
> command prompt, I decided to change the name of 'my directory' to 
> 'mydirectory' using the command 'mv -ivT my\ directory mydirectory'. Although 
> command succeeded, when I wanted to save the text file which I was working on 
> I got an error from my text editor saying the directory does not exist. This 
> is due to the name change of the parent directory of the .txt-file.
> 
> I hope the problem is clear by above example. If there already exists such 
> safeguard by providing some specific option to the mv command, then please 
> discard this email and my apologies.
> 
> 
> With kind regards,

While I see the issue, I think it's probably outside the remit
of mv to make such checks. Depending on how the open file
is being processed, it may be immune to renames.
I.E. if the file descriptor is just being manipulated,
then naming is irrelevant. Also if name operations are
done on relative paths and the rename is higher in the
directory hierarchy, again the rename is irrelevant.

I'm thinking that something external to mv could be used here, like:

safe_rename() { lsof +D "$1" >/dev/null 2>&1 || mv "$1" "$2"; }

Note however lsof as presented there at least doesn't support
this with the correct exit code, due to it requiring _all_ files
rather than _any_ files in the hierarchy under "$1" to be open.
This is also a very expensive operation as noted in the lsof man page.

cheers,
Pádraig.