3

I am attempting to move a file from one directory to another on a CIFS mounted file system using the command:

mv /mnt/development/Backup/NagiosServer/latest/* /mnt/development/Backup/NagiosServer/daily/

This produces the error message:

mv: '/mnt/development/Backup/NagiosServer/latest/20190512-backup.zip' and '/mnt/development/Backup/NagiosServer/daily/20190512-backup.zip' are the same file

The target file in the .../daily/ directory definitely does not exist at this point.

This is the listing of the relevant directories after the error occurs:

nagios@nagios-server:~$ mv /mnt/development/Backup/NagiosServer/latest/* /mnt/development/Backup/NagiosServer/daily
mv: '/mnt/development/Backup/NagiosServer/latest/20190514-backup.zip' and '/mnt/development/Backup/NagiosServer/daily/20190514-backup.zip' are the same file
nagios@nagios-server:~$ ls -lsha /mnt/development/Backup/NagiosServer/latest/
total 3.5G
   0 drwxr-xr-x 2 nagios root    0 May 15 08:00 .
   0 drwxr-xr-x 2 nagios root    0 May 13 15:15 ..
3.5G -rwxr-xr-x 1 nagios root 3.5G May 14 17:13 20190514-backup.zip
nagios@nagios-server:~$ ls -lsha /mnt/development/Backup/NagiosServer/daily
total 18G
4.0K drwxr-xr-x 2 nagios root 4.0K May 15 08:00 .
   0 drwxr-xr-x 2 nagios root    0 May 13 15:15 ..
3.5G -rwxr-xr-x 1 nagios root 3.5G May  8 17:12 20190508-backup.zip
3.5G -rwxr-xr-x 1 nagios root 3.5G May  9 17:12 20190509-backup.zip
3.5G -rwxr-xr-x 1 nagios root 3.5G May 10 17:12 20190510-backup.zip
3.5G -rwxr-xr-x 1 nagios root 3.5G May 11 17:14 20190511-backup.zip
3.5G -rwxr-xr-x 1 nagios root 3.5G May 12 17:12 20190512-backup.zip

The listing of the unmounted mount point shows nothing:

nagios@nagios-server:~$ ls /mnt/development/
nagios@nagios-server:~$

I followed the advice found here to disable CIFS caching, which works, but only the first time the mv is attempted. Thereafter it fails with the same error message.

What is going on here?

I am running under Ubuntu 18.04 and the mounted CIFS file system is on a remote Windows 10 machine. Also, The Windows machine is running a VirtualBox VM that also runs Ubuntu 18.04. The mv command works without issue when run from the VM.

Improve this question

1 Answer 1

Reset to default
1

They are the same file, in the sense that there would be a collision in these files during the move. It might be more clear if the language file name was used instead.

This is warning you that you're moving files from the source to the destination, and that file, or filename already exists at the destination. This means that there is a chance that you will lose data. This existing file will be overwritten.

You can use --interactive or --force flags to change this behavior, but you must understand what you are doing.

$ man mv
...

       -f, --force
              do not prompt before overwriting

       -i, --interactive
              prompt before overwrite

       -n, --no-clobber
              do not overwrite an existing file

       If you specify more than one of -i, -f, -n, only the final one takes effect.

When you issue the command the first time, some files are moved from the source to the destination, until this file is to be moved. At that time, mv errors and warns you about the situation. Be wary that at this point, you haven't completed the move. You're not copying, so many source files may not exist in the original directory.

If you know that you do not want the data currently at the destination /mnt/development/Backup/NagiosServer/daily/20190512-backup.zip, remove it before issuing the mv command, or forcefully overwrite existing files.

I recommend that you also look into rsync and its capabilities.

Improve this answer
5
  • Thanks earthmeLon. I had meant to include this listing in my original question, but I did mention that the target did not exist. The listing of the target directory is: ls /mnt/development/Backup/NagiosServer/daily/ 20190508-backup.zip 20190509-backup.zip 20190510-backup.zip 20190511-backup.zip As you can see the target does not exist. Also, it doesn't explain why it always works the first time, but never again until I reboot (or flush), even if I manually delete the target before doing so.
    – M. Webb
    May 14, 2019 at 5:07
  • Please update your question with the output of ls -lsha /mnt/development/Backup/NagiosServer/latest/ and ls -lsha /mnt/development/Backup/NagiosServer/daily/. Please do this after receiving the error message, so mv, ls, ls. You'll either see what I'm saying, or we will have additional information to help you figure it out.
    – earthmeLon
    May 14, 2019 at 16:48
  • Oh, please also list the mounted directory, unmounted. So, if it's /mnt/development/, then please show us the listing of that unmounted. We need to make sure it's empty :D.
    – earthmeLon
    May 14, 2019 at 16:53
  • I've added the requested listings to the question. In doing this I noticed that the first time I did the mv it worked ok. I then went to the windows machine and cut/paste the moved file back into the .../latest directory from the .../daily directory to try again. This time it failed with the results shown in my edited question. Given that applying the fix mentioned in my question appears to resolve the issue temporarily, I have to assume it's some kind of inode caching issue. While I'd still like to understand wh' is going on here, mv -f appears to resolve the problem.
    – M. Webb
    May 14, 2019 at 22:12
  • Glad you made some progress. I have to mention now that I feel I've experienced a similar issue with sshfs yesterday. I was forced to remove the file on the host machine itself, vs the mount. I've never run into this issue and am investigating recent changes.
    – earthmeLon
    May 16, 2019 at 18:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.