Is it risky to rename folder with 180GB with the mv command?

We have a folder /data that contain 180GB.

We want to rename the /data folder to /BD_FILES with the mv command.

Is it safe to do that?

  • 14
    Why and how should it be risky? If you're unsure, call mv with the -i option.
    – dessert
    Sep 24, 2017 at 17:00
  • 5
    Is there anything in your environment that leads you to think that it might be risky?
    – Jeff Schaller
    Sep 24, 2017 at 17:13
  • 2
    Do you mean whether there's a risk that the act in and of itself could cause a problem, or whether there's a risk that there could be problematic effects? If you have any programs that are expecting there to be a /data folder, then renaming it could cause problems. Sep 24, 2017 at 23:48
  • 3
    Side-note: Almost everything is safe if you have verified backups. Nothing is as safe as it should be if you don't. In other words: when asking "is it safe", your first thought should be "have I verified my backups?" Sep 25, 2017 at 14:34
  • 2
    I mean risk that could be problematic when moving huge folder with data by this OS could stop the moving in the middle for example or loose data
    – yael
    Sep 25, 2017 at 22:08

5 Answers 5


Changing the name on a folder is safe, if it stays within the same file system.

If it is a mount point (/data kinda looks like it could be a mount point to me, check this with mount), then you need to do something other than just a simple mv since mv /data /BD_FILES would move the data to the root partition (which may not be what you want to happen).

You should unmount the filesystem, rename the now empty directory, update /etc/fstab with the new location for this filesystem, and then remount the filesystem at the renamed location.

In other words,

  1. umount /data
  2. mv /data /BD_FILES (assuming /BD_FILES doesn't already exist, in that case, move it out of the way first)
  3. update /etc/fstab, changing the mount point from /data to /BD_FILES
  4. mount /BD_FILES

This does not involve copying any files around, it just changes the name of the directory that acts as the mount point for the filesystem.

If the renaming of the directory involves moving it to a new file system (which would be the case if /data is on one disk while /BD_FILES is on another disk, a common thing to do if you're moving things to a bigger partition, for example), I'd recommend copying the data while leaving the original intact until you can check that the copy is ok. You may do this with

rsync -a /data/ /BD_FILES/

for example, but see the rsync manual for what this does and does not do (it does not preserve hard links, for example).

Once the folder is renamed, you also need to make sure that existing procedures (programs and users using the folder, backups etc.) are aware of the name change.

  • 9
    There is the risk that one expects mv to just do a rename system call, but due to circumstances one hasn't realized it is going to copy the files and delete the original. If I need to be absolutely certain just a rename system call is made and mv isn't going to do something "clever" behind my back I open a Python shell and use os.rename.
    – kasperd
    Sep 25, 2017 at 6:43
  • 3
    With a relatively recent Linux kernel you can move the mount point instead: mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data Sep 25, 2017 at 10:30
  • 2
    @MichealJohnson That'll probably work on a Linux system, yes. The neat thing with rsync is that it's restartable.
    – Kusalananda
    Sep 25, 2017 at 13:18
  • 3
    @MichealJohnson One uses the tools that one is most comfortable using, obviously. Yes, rsync -a preserves almost all metadata, but not hard links, ACLs or extended attributes (add -HAX for that).
    – Kusalananda
    Sep 25, 2017 at 14:20
  • 3
    @Max Different distributions have different rename commands with different behavior. I think that is reason enough to not use the rename command when you want to be certain what it is going to do.
    – kasperd
    Sep 25, 2017 at 15:50

You aren't renaming every file in the directory, you're renaming one file in /. That's because:

  1. directories are files, and
  2. the file system really cares about the inode, not the actual text.

Thus, renaming a directory, no matter how many files or how much data is in it, is trivial.


If you just rename (source and target in same file system), it is simply a rename of a directory entry. It either succeeds and the directory has new name, or fails in which case nothing changes *.

If the source and target are on different file systems the data needs to be copied by mv. Differences in file system features, such as maximum file size, limitations in file names, etc., can cause problems. To avoid issues, first copy files (cp, rsync, …) and after copy completes successfully, remove the files in the original location.

* However there are some corner cases, for example mentioned in the BUGS section in man 2 rename

  • >"It either succeeds and the directory has new name, or fails in which case nothing changes". How it's guaranteed? Is it true for all filesystems? Are there any documentation about this?
    – turbanoff
    Sep 25, 2017 at 9:04
  • Rename is a single syscall, however there is a note about NFS in BUGS section of man rename: rename can be successful even when error is returned when using NFS (see details in the man page). I added a note in the answer too. I don't expect any file system in kernel to consider it acceptable for a directory entry vanish should a rename fail.
    – sebasth
    Sep 25, 2017 at 9:32

As others have said, renaming a folder poses no inherent risk to the contents. But there is a different kind of risk you may want to consider.

Existing procedures, scripts, user-defined shortcuts, and configurations which reference the original location could be broken by this change, and if the paths are stored in a database, for example, updating them could be a big job.

One thing you can do is make a symbolic link for the new directory name, but leave the old name in place for a while. That will give you time to evaluate the impact of this change. You could temporarily remove the old name, see if there are any problems, and if there are, just recreate the old name so people can continue working while you figure out what needs to be updated.

A command something like this should do it : ln -s /data /BD_FILES

  • 4
    One more mild risk that no-one has mentioned yet, is that depending on your backup strategy for that folder, it might lead to disk space and latency issues on the backup drive due to 180GB of "new" data suddenly appearing, and needing to be backed up.
    – Kent
    Sep 25, 2017 at 6:10
  • I prefer something like mv thing1 thing2 ; ln --symbolic ./thing2 thing1. That way I've got the new name and can easily test absence of the old by deleting the symlink. Sep 25, 2017 at 18:29

Rename is atomic. The only reasonable risk is that mv decides to copy everything for some reason and that crashes half way through. If you have GNU mv, mv -T will remove this risk.

mv -T tells mv that it's moving to a non-folder; which will cause it to refuse to do mkdir() which in turn will cause it to fail if moving a folder and it decided to copy for some reason.

I was involved in shaking bugs out of mv -T while working on my master's thesis years ago. It used to do the wrong thing on too many edge cases.

On the other hand, you have 180GB of user data on the root partition. You probably do want to move this off the root partition.

  • You can't possibly tell from the name alone if something is in the "root partition" or not.
    – Peter
    Sep 26, 2017 at 15:03
  • @Peter: If it's not on the root partition it's a mountpoint. You can't rename mounted mountpoints with the mv command.
    – Joshua
    Sep 26, 2017 at 15:08

You must log in to answer this question.

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