0

I'm running into a very strange problem: I can't simply move all contents of dir A to dir B on the same drive. The size is 500 GB and I have 24 GB free, yet it fails. Why does it require all these 500 GB again for moving the files?

I have tried different file managers: Krusader, Dolphin, the command mv, mc, they all fail. The reason is simple: They don't erase a file after it has been moved, they first want to copy all files to the destination and then delete them at the source. This is obviously not what I want, as I don't have another 500 GB free.

The mv command fails, as cannot move files into already existing dirs (even when empty, as sub dirs are considered files too and all the tools for some strange reason create all the directories first before moving or copying)

I can of course do it file by file, or individual directories, but this is a Dropbox folder of 190'000 files and thousands of directories, so it is not feasible.

The solution I think would work: Is there a GUI tool (TUI or GUI) tool that deletes files at the source immediately after moving them? You would think that this is just common sense, but all the commands that I tried seem to confuse move with copy and do exactly the same.

I can't just rename the directory, it is a quirk that Dropbox has that you can't relink a new install to an existing Dropbox directory, but have to rename the old one, Dropbox creates a new directory and then I want to move the files and there I am, stuck.

I would rather not use rsync for this, as it does not remove the directories at the source and then it gets ugly and messy, I want to see if there is a GUI/TUI before I write my own mv command that actually gets the job done.

Improve this question
5
  • How deep does the Dropbox "quirk" (bug?) go? If it is only one level of directory that cannot be re-linked, then you can just work one level below, and mv the second-level directory names into the Dropbox structure. You should not need to move any lower levels, or any files.
    – Paul_Pedant
    Commented Sep 21, 2021 at 7:27
  • So you don't want to move "all contents of dir A to dir B", you have an existing directory hierarchy as destination subtree, and you want to move into that subtree? And there isn't anything funny in the way, like mountpoints? If yes, have you tried find coupled with mv for each file? Because mv should work for individual files with an (existing) subdirectory as destination. If it doesn't, you have a different problems. And if the hierarchy at the destination is not complete, you need to create all directories first (different call with find).
    – dirkt
    Commented Sep 21, 2021 at 7:38
  • It is very simple and has happened to me like 1000 times sofar in the last 10 years: I want to move dir A to another drive (or the same drive in this case) I star the move, something happens, it gets interrupted. Now I have to resume it, just that it can't for many reasons. The directory structure is identical and my intent is that dir A moves to dir B, IDENTICALLY, all files get moved and are then erased at the source. There is nothing in directory B, so no merging takes place. All files already in B are not in A anymore (because I'm moving them, not copying them)
    – Markus Bawidamann
    Commented Sep 21, 2021 at 8:01
  • I see now what the main problem is: The file manager (Krusader) refuses to overwrite a file with an identical file unless there is double the space of the moving file available. If I have a file that is 4 GB and it exists at the source and destination, identical, it won't replace it unless there is another 4 GB extra available. That is very strange. I'm pretty sure that is new: I end up in that situation many times, since if the move fails, no files get erased (or supposedly none), but some are copied already.
    – Markus Bawidamann
    Commented Sep 21, 2021 at 8:16
  • Use cp -l (just hard link). After the copy you can delete the original folder.
    – K-attila-
    Commented Sep 21, 2021 at 9:42

1 Answer 1

Reset to default
0

I created a directory named dira, and dira/tt, and touched dira/hh and dira/tt/anotherfiloe

ls dir*
hh  tt
ls dir*/tt
anotherfiloe

After that: Not copy, just hard link the files

cp -l -r dira dirb

Check:

ls dir*/tt
dira/tt:
anotherfiloe
dirb/tt:
anotherfiloe

I can delete the source now:

 rm -r dira

Check:

ls dir*/tt
anotherfiloe
ls dir*
hh  tt
Improve this answer
5
  • But hard links are the same as the original file, if you erase a hard link, you erase the file itself if I'm not mistaken. Otherwise it would be a symbolic link.
    – Markus Bawidamann
    Commented Sep 21, 2021 at 10:31
  • No. Before copy dira/hh, dira/tt/anotherfileoe After copy, dira/hh, dirb/hh, dira/tt/anotherfileoe, dirb/tt/anotherfileoe. You can remove dira, you delete just the hardlinks, not the file.... (It's working just the same filesystem, of course.)
    – K-attila-
    Commented Sep 21, 2021 at 10:40
  • Hint: rtfm.co.ua/en/what-is-hard-link-symlink-and-inode-in-linux
    – K-attila-
    Commented Sep 21, 2021 at 10:47
  • 1
    @MarkusBawidamann The rule is that the file contents (i.e. inode) is removed when the last hard link to it is removed. (Actually, also deferred until the last open file descriptor relating to that inode is closed.)
    – Paul_Pedant
    Commented Sep 21, 2021 at 16:17
  • Yes. + if last hard link removed, but the file is open, you can restore it.....
    – K-attila-
    Commented Sep 22, 2021 at 10:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .