viking777 Posted February 15, 2009 Report Share Posted February 15, 2009 Is there some clever command line way to remove a 'containing' folder without removing the files within it? Example - My directory structure is A/B/files, but what I want is A/files ie get rid of /B. The only way I know how to do it at the moment is to move '/files' from /B to /A then delete the folder /B. I presume this is the only way to do it? It is just that if /files is large it takes a long time to move them and I wondered if there was a better way? It would be a lot quicker to be able to just delete /B and have the files magically appear under /A. I have a feeling this isn't possible. :unsure: Quote Link to comment Share on other sites More sharing options...
neddie Posted February 15, 2009 Report Share Posted February 15, 2009 If A is empty apart from B, you could always do this: mv A/B . rmdir A mv B A But your way should be pretty fast, no matter how big the files are. The files aren't really moved or copied anywhere, just the directory contents are updated. Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted February 15, 2009 Report Share Posted February 15, 2009 If you want to remove folder B with the files in it, just do: rm -rf B just be careful with the rm -rf command else you could wipe out stuff you don't mean to. Quote Link to comment Share on other sites More sharing options...
viking777 Posted February 15, 2009 Author Report Share Posted February 15, 2009 No, No, No, you have misunderstood me there Ian. Under no circumstances do I want to remove the files inside /B I only want to remove the folder itself - definitely not the files as well! Quote Link to comment Share on other sites More sharing options...
viking777 Posted February 15, 2009 Author Report Share Posted February 15, 2009 I see what you are getting at neddie, but the point about it is (and I didn't say this in the original post because I thought it would just complicate it ) these fies were on a usb key so moving them was not as quick as you might think (there were 350Mb worth). Another thing I should perhaps make clear is that I have already done what I wanted to do, the point of this post was simply to learn if there was perhaps a better way to achieve what I wanted instead of the way I chose to do it. Quote Link to comment Share on other sites More sharing options...
neddie Posted February 15, 2009 Report Share Posted February 15, 2009 these fies were on a usb key so moving them was not as quick as you might think (there were 350Mb worth).Yeah but still the time it takes depends more on the number of files which have to be moved (assuming they're being moved within the same device) rather than the size, as the files themselves don't move, just the pointers to them. But the reason I suggested moving the directory (instead of moving each file in turn) is that even if there are a boatload of files in there, moving the directory just updates a single entry rather than one for each file. So it should be even faster. Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted February 15, 2009 Report Share Posted February 15, 2009 No, No, No, you have misunderstood me there Ian. Under no circumstances do I want to remove the files inside /B I only want to remove the folder itself OK, sorry :) you can ignore me then - it wasn't clear when I first read your post, then when I just re-read it with that thought in mind, I then realised you just wanted the folder gone and not the files! Quote Link to comment Share on other sites More sharing options...
{BBI}Nexus{BBI} Posted February 15, 2009 Report Share Posted February 15, 2009 Moving files always takes longer than copying them. Quote Link to comment Share on other sites More sharing options...
neddie Posted February 16, 2009 Report Share Posted February 16, 2009 Moving files always takes longer than copying them.What?! Not for me, and certainly not when the files are moved within the same drive. Then, moving is much faster! Quote Link to comment Share on other sites More sharing options...
{BBI}Nexus{BBI} Posted February 16, 2009 Report Share Posted February 16, 2009 What?! Not for me, and certainly not when the files are moved within the same drive. Then, moving is much faster!No way is moving faster than copying. I'm not talking about a few bytes or megabytes here. I'd be interested in your timings if you're prepared to do a test with say a 3-4gb file. :unsure: Quote Link to comment Share on other sites More sharing options...
ianw1974 Posted February 16, 2009 Report Share Posted February 16, 2009 Moving is quicker, and so I thought I'd do the test: ian@esprit:~$ dd if=/dev/zero of=file bs=1024 count=4096000 4096000+0 records in 4096000+0 records out 4194304000 bytes (4.2 GB) copied, 203.254 s, 20.6 MB/s created a 4GB file. ian@esprit:~$ time cp file file2 real 5m43.710s user 0m0.348s sys 0m29.486s shows that the copy took 5 mins and 43 seconds. ian@esprit:~$ time mv file Downloads/ real 0m0.047s user 0m0.000s sys 0m0.008s shows that the move took less than one second! Quote Link to comment Share on other sites More sharing options...
theYinYeti Posted February 16, 2009 Report Share Posted February 16, 2009 (edited) Nexus, I can confirm neddie is right in most circomstances :) If you move files within the same partition, then only pointers to those files (the inodes, or “TOCâ€) are updated; there's no copy+delete. That's what allows the mv to have this wonderful property within a partition: the move is atomic, at least for each single file (see further down). If you move files from a partition to another, then indeed this move is longer than a copy because it is a copy AND a delete. What I don't know is wether inodes are a tree (A -> {B -> {files…}, …}, …) or a list (A, A/B, A/B/files, …). Depending on this, moving a directory (not a single file) may imply updating two inodes (old parent + new parent) or as many inodes as there are entries within the moved directory (recursively). I guess this depends on the filesystem… Yves. [edit] If the inodes are a tree, then following on neddie's idea, it might be faster to do so (depending on the number of entries): — move A/* except A/B into A/B/, — move A/B to TMP_NAME, — remove A and rename TMP_NAME to A. This would work even if A doesn't only contain B, but the difference is bound to be negligible, so in my opinion not worth the effort. Edited February 16, 2009 by theYinYeti Quote Link to comment Share on other sites More sharing options...
viking777 Posted February 16, 2009 Author Report Share Posted February 16, 2009 Amazing! I didn't think my little post at the start would generate such an interesting discussion, but the subsequent posts have been most interesting. Thanks to everyone. Quote Link to comment Share on other sites More sharing options...
{BBI}Nexus{BBI} Posted February 16, 2009 Report Share Posted February 16, 2009 (edited) Nexus, I can confirm neddie is right in most circomstances :) If you move files within the same partition, then only pointers to those files (the inodes, or “TOCâ€) are updated; there's no copy+delete. That's what allows the mv to have this wonderful property within a partition: the move is atomic, at least for each single file (see further down). If you move files from a partition to another, then indeed this move is longer than a copy because it is a copy AND a delete. What I don't know is wether inodes are a tree (A -> {B -> {files…}, …}, …) or a list (A, A/B, A/B/files, …). Depending on this, moving a directory (not a single file) may imply updating two inodes (old parent + new parent) or as many inodes as there are entries within the moved directory (recursively). I guess this depends on the filesystem… Yves. [edit] If the inodes are a tree, then following on neddie's idea, it might be faster to do so (depending on the number of entries): — move A/* except A/B into A/B/, — move A/B to TMP_NAME, — remove A and rename TMP_NAME to A. This would work even if A doesn't only contain B, but the difference is bound to be negligible, so in my opinion not worth the effort. Thank you theYinYeti, I was going to post the results of that very same thing. Moving to another location other than the current drive is longer. Yes you are correct ianw1964, I got the same timing as you when moving to the same drive. :) Edited February 16, 2009 by {BBI}Nexus{BBI} Quote Link to comment Share on other sites More sharing options...
viking777 Posted February 16, 2009 Author Report Share Posted February 16, 2009 Yeah but still the time it takes depends more on the number of files which have to be moved (assuming they're being moved within the same device) rather than the size, as the files themselves don't move, just the pointers to them. But the reason I suggested moving the directory (instead of moving each file in turn) is that even if there are a boatload of files in there, moving the directory just updates a single entry rather than one for each file. So it should be even faster. Neddie, I have just done an experiment with the code you suggested and I must say it worked faultlessly and instantaneously. There are only two problems with it. Firstly I didn't know it when I wanted it and secondly I will never remember it the next time I want it - so can I have your phone number :lol2: Seriously though, respect, if I carry on learning stuff like that I might become a cli lover!! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.