GNU bug report logs -
#14628
mv: safeguard against renaming dir with open files
Previous Next
Reported by: "S. Dara" <saif.dara <at> gmail.com>
Date: Sat, 15 Jun 2013 20:18:02 UTC
Severity: wishlist
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 6 years and 216 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.