The Move Command
What if the move command was transactional? Ie if a user wants to move /home/sharms/testdir to /usr/testdir, and /usr/testdir runs out of space in the middle, ie:
sharms@mugatu:~/Desktop$ mv *.tar.* ../tmp/
mv: writing `../tmp/Neu-0.6-PR3.tar.bz2': No space left on device
Then you might have like half of the files copied over. If it was transactional, and failed, then it could say “An error occurred, would you like to rollback this move?”. Does that sound useful to anyone?
Related posts:
#1 by Edgeman on October 16, 2007 - 11:57 am
Quote
Yea it sounds useful to me, I’d like the ability to undo whatever change I just made so that I can do it properly after fixing the problem.
#2 by Bram on October 16, 2007 - 12:05 pm
Quote
That would be really cool! Another way to fix this problem is to first check if there is enough disk space to complete the operation, although this won’t work when you’re extracting/copying/… in multiple instances at the same time.
#3 by Daniel on October 16, 2007 - 12:13 pm
Quote
That would be very useful, but just as you said, by giving an option, not the way Windows Explorer does it, if one file fails, the whole operation fails. This can be quite annoying.
#4 by Edward A Robinson on October 16, 2007 - 12:16 pm
Quote
Seems like a no brainier to me
#5 by LGB on October 16, 2007 - 12:23 pm
Quote
Yes
But it’s not a new idea.In theory, rename a file works this way. There’s a general idea to decrease the gap between relational databases (like an SQL RDBMS) and filesystems (they’re hierarchival databases in fact). It sounds usefull to have sys_begin() and sys_commit()/sys_rollback() system calls (or something likethese) to group any number of file I/O into one transaction like BEGIN/COMMIT/ROLLBACK in case of SQL. In fact, reiser4 filesystem contains (or would contain?) this kind of notion the “only” problem that there’s no standard API for this not even at level of VFS … Af far as I know, of course.
#6 by Jesse Jarzynka on October 16, 2007 - 1:06 pm
Quote
I agree that checking before the move would be a nice option and also if it does run out of space how about a “Would you like to move the remaining files somewhere else?”. That way you could plug in a USB drive or something.
#7 by Wolfger on October 16, 2007 - 1:42 pm
Quote
Heck yeah! I’ve wanted this feature at least once in the past. Not that I, you know, thought about actually implementing such a thing…
#8 by Eric Honaker on October 16, 2007 - 2:28 pm
Quote
I would love to see that.
#9 by Eduardo on October 16, 2007 - 2:58 pm
Quote
I use very litle partitions for /boot, /var and /tmp, so this may be usefull, yes. I think I could write a transmv.py …
#10 by dcollins on October 16, 2007 - 5:18 pm
Quote
Good idea, I would like to see this implemented. Here’s my input:
To me, a “transactional” move command means either all the files are successfully moved or none of them – the initial state remains unchanged if an exceptional condition occurs. By default I don’t really want to be asked if I want to roll back the changes, I want to command to just do it. Perhaps consider the ability to specify the desired behavior as a command line option.
#11 by Andrew Conkling on October 16, 2007 - 5:22 pm
Quote
I believe Nautilus already does this when canceling a move/copy; perhaps it does when running out of space too?
#12 by flamepanther on October 16, 2007 - 8:19 pm
Quote
This sounds exceedingly useful. I’ve wanted a feature like that for a long time.
#13 by Rudd-O on October 16, 2007 - 11:35 pm
Quote
Sounds extremely useful. I understand that ReiserFS 4 has transactional semantics that can be leveraged to do something like this *but* I doubt it’s cross-filesystem. Windows Vista does have this ability.
#14 by Justin Lynn on October 17, 2007 - 1:10 am
Quote
Yes, I would say that would be nice. Any idea what it would take to implement?
#15 by sipster on October 17, 2007 - 4:51 am
Quote
very usefull!
#16 by Jason Brower on October 17, 2007 - 5:47 am
Quote
Sounds like a great idea. I know there is a demand for it in gnome. Why not start this fix where it should. At the command line.
#17 by Azrael Nightwalker on October 17, 2007 - 9:03 am
Quote
This is an excellent idea. Why don’t you add a spec on launchpad and ubuntu wiki or post it directly to GNU coreutils developers?
#18 by mallux on October 17, 2007 - 9:11 am
Quote
One potential problem is that POSIX states that you shouldn’t delete the source before the destination is written (see http://kerneltrap.org/man/linux/man1p/mv.1p) which implies that for a substantial transaction you would need enough space to store all of src and dst at the same time (which is not true when moving the files individually).
#19 by sharms on October 17, 2007 - 9:11 am
Quote
I took a look at the source (it is in the coreutils package) and the source code for the ‘mv’ command is not that daunting. Going to play with it when I get some free time.
#20 by qhartman on October 17, 2007 - 1:03 pm
Quote
It is for this very reason I use rsync followed by rm rather than mv on big or important moves.