Jump to content

Remove containing folder


Recommended Posts

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:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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:
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by theYinYeti
Link to comment
Share on other sites

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 by {BBI}Nexus{BBI}
Link to comment
Share on other sites

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: :lol2:

 

Seriously though, respect, if I carry on learning stuff like that I might become a cli lover!!

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...