Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Watch out for mv command and symlinks on Samba shares UNIX
I just lost a full day's worth of work. Here is how you can too ... on a Samba share, do this:
 % mkdir something 
 % ln -s something something_else 
On Mac OS X in the shared directory, do this:
 % cd something_else 
 % touch test_file 
 % mv test_file ../something 
 mv: rename test_file to ../something/test_file: No such file or directory 
Watch it all go bye-bye.

I guess there are still bugs with the mv command. It should have said that the files were the same. If I realized that the directory that I was working in was a soft link to the main directory, I would not have tried to move the files.

[robg adds: Unix wizards, is this expected behavior out of mv? It seems wrong to me, but I don't know enough about what's normal in Unix...]
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[9,442 views]  

Watch out for mv command and symlinks on Samba shares | 10 comments | Create New Account
Click here to return to the 'Watch out for mv command and symlinks on Samba shares' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Watch out for mv command and symlinks on Samba shares
Authored by: beerguy on Nov 06, '03 11:21:16AM

Actually I think there is a bug here but it's not what the poster was geting at. The mv command should complain that target and destination are the same file.

[iMac-otto:~] otto% mkdir something
[iMac-otto:~] otto% ln -s something something_else
[iMac-otto:~] otto% cd something_else
[iMac-otto:~/something_else] otto% touch foo
[iMac-otto:~/something_else] otto% mv foo ../something
[iMac-otto:~/something_else] otto% ls
foo
[iMac-otto:~/something_else] otto% cd ..
[iMac-otto:~] otto% cd something
[iMac-otto:~/something] otto% ls -l
total 0
-rw-r--r-- 1 otto staff 0 6 Nov 08:13 foo


It works like it's supposed to here. It is considered bad form to not use full pathnames when making sym links.


Also consider the directory structure when you link.

Let's say I had a directory called /data/stuff/files

and I link it to /users/mystuff/files/backup

(cd /users/mystuff/files; ln -s /data/stuff/files backup)

If I cd /users/mystuff/files/backup and then do a cd .. I will be in /data/stuff not /users/mystuff/files. That can lead to confusion and files that seem to be lost but really aren't.

Cheers



[ Reply to This | # ]
Watch out for mv command and symlinks on Samba shares
Authored by: mojo6771 on Nov 06, '03 12:21:19PM
On freebsd 4.5, the move works without a error.

On Redhat 6.2 it gives a error as: mv: `c' and `../a/c' are the same file.

--
From the above post, it appears OS X works similar to freebsd.
The Samba share is most likely messing up.


[ Reply to This | # ]
Watch out for mv command and symlinks on Samba shares
Authored by: Spades on Nov 06, '03 11:58:39AM

The problem is probably Samba. Last I knew, Samba is not quite the same as other unix filesystems, but 3.0 may be different. Unless it has changed, I don't think Samba creates symlinks the same way other filesystems do. There could be many different types of filesystems on the other side of Samba, including ones that don't support symlinks like FAT32. Because of this, symlinks on Samba are a little bit of a hack. I think the problem isn't a mv bug, but a Samba issue.



[ Reply to This | # ]
Watch out for mv command and symlinks on Samba shares
Authored by: rtl on Nov 06, '03 12:18:25PM
This example is equivalent to issuing the command mv foo foo with a file named foo in the current directory, i.e. you're overwriting a file with itself. On a local HFS+ or UFS filesystem, this really shouldn't cause any harm, but it looks like the poster has discovered that this isn't a safe operation on a windows share. This is probably a bug that should be reported to Apple - the rename operation is probably being translated into the wrong sequence of smb operations.

Until this is fixed, you can help prevent it in the future by aliasing mv to mv -i, which gives you an "are you sure?" prompt before any potentially destructive operations. You might also consider doing the same for the cp and rm commands. In order to add such aliases to your environment, add these lines to your .tcshrc file if you are using tcsh:

  alias rm 'rm -i'
  alias mv 'mv -i'
  alias cp 'cp -i'

For bash, add this to your .bashrc:

  alias rm='rm -i'
  alias mv='mv -i'
  alias cp='cp -i'

These have been mentioned in several comments in the past, but seemingly never as a hint. Does one the of the Mac OS X bibles have a section on well-known UNIX shell additives that would be useful to newbies?

[ Reply to This | # ]

Watch out for mv command and symlinks on Samba shares
Authored by: ahbe on Nov 06, '03 12:57:39PM
Small correction, use .profile in the root of your home directory, not .bashrc Than make sure you shutdown that terminal session and start again. It should work now. BTW, I believe this is standard operation with the mv command, at least in Linux that's how it works. That is why the "-i" option exists, to warn you. Normally what you say is what it does. Be careful with the command line. On at least two occasions, I did a "rm -r *" thinking I was in the "/tmp" directory, when I was actually at the root while logged on as root. By the time you realize what you just did, its to late. Be careful!

[ Reply to This | # ]
root implies being careful
Authored by: hayne on Nov 06, '03 02:10:20PM
On at least two occasions, I did a "rm -r *" thinking I was in the "/tmp" directory, when I was actually at the root while logged on as root.
This would seem to indicate that you should not log on as root.

[ Reply to This | # ]
root implies being careful
Authored by: bluehz on Nov 06, '03 07:38:32PM

Actually this happened to me the other day while connected smb to my linux box. I deleted a symlink file toa dir in the Finder and it deleted the actual dir. Luckily it wasn't anything important.



[ Reply to This | # ]
Watch out for mv command and symlinks on Samba shares
Authored by: jimhill on Nov 06, '03 12:59:06PM

No, NO, NO!!!!

Do not alias system commands! I can't repeat that strongly enough. If you want the system to hold your hand with "-i" flags, then for the love of God use aliases like "rmi", "cpi", and "mvi". Because if you don't, you _will_ find yourself working on another machine or another account and you'll blow your feet off with no safety net.

Rob -- it would be a grievous error on your part to include "use alias rm 'rm -i'" in any hint. Ever.


---
Mac OS X: Because making UNIX simple is easier than debugging Windows.



[ Reply to This | # ]
solution: "mv" from GNU FileUtils
Authored by: blakers on Nov 06, '03 02:08:21PM
The "mv" util that ships with Panther complains about symlinks in general ... The (a?) fix is to upgrade to the "mv" from GNU FileUtils v4.1 here's the quick step-by-step to get/build/install it:

fileutils-4.1:
reference URL: coreutils
Downloads: fileutils-4.1.tar.gz

% unsetenv CFLAGS CPPFLAGS CXX CXXFLAGS LDFLAGS LDDLFLAGS ;\
% setenv CFLAGS "-no-cpp-precomp"

% gnutar zxf fileutils-4.1.tar.gz

% cd /usr/ports/fileutils-4.1

% ./configure \
--prefix=/usr/local/fileutils \
--disable-nls

% make
% make install

% mv /usr/local/fileutils/bin/mv /bin/mv

% rehash


[ Reply to This | # ]
Watch out for mv command and symlinks on Samba shares
Authored by: bluestar on Nov 06, '03 08:05:55PM

You also have to be aware of what's behind the Samba server. If its underlying filesystem doesn't support symlinks (FAT, NTFS) your Mac shouldn't let you create them.

There's also a tcsh variable 'symlinks'. If you "set symlinks = chase" then it will follow symlinks. If you cd into one it will follow the link and actually cd into what the symlink points to.

So after "cd something_else" your current working directory would've been "something".



[ Reply to This | # ]