Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Nov 2011 18:53:58 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Chris <cpuburner@gmail.com>
Cc:        Michael Sierchio <kudzu@tenebras.com>, freebsd-questions@freebsd.org
Subject:   Re: recursive copy with spaces in descendants
Message-ID:  <20111107180715.U72449@sola.nimnet.asn.au>
In-Reply-To: <20111105225546.91B0C1065764@hub.freebsd.org>
References:  <20111105225546.91B0C1065764@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 387, Issue 10, Message: 34
On Sat, 5 Nov 2011 18:49:29 -0400 Chris <cpuburner@gmail.com> wrote:
 > On Sat, Nov 5, 2011 at 6:20 PM, Michael Sierchio <kudzu@tenebras.com> wrote:
 > > On Sat, Nov 5, 2011 at 3:15 PM, Chris <cpuburner@gmail.com> wrote:
 > >> I apologize for the lack of detail. The command I'm using is:
 > >> ( cd /usr/local/etc/transmission/home/Downloads/ ; tar cf - . ) | ( cd
 > >> /mnt/usb ; tar xf - )
 > >
 > > Show, don't tell. What does tar report when you run it?

Indeed this helps, especially now we also know it's msdosfs ..

 > The following messages display:
 > 
 > ./: Can't set user=921/group=921 for .
 > ./Reboot S1 - 01 [3FD6C4B2].mkv: Can't create 'Reboot S1 - 01 [3FD6C4B2].mkv'
 > 
 > The last message (can't create) repeats for all files in the
 > directory. Running 'ls -al /mnt/usb' yields:
 > 
 > drwxr-xr-x   1  root    wheel         32768    Dec 31 1979  .
 > drwxr-xr-x   1  root    wheel             512    Nov  5 03:04  ..
 > 
 > Where /mnt/usb was originally empty in the first place.

Something I've seen noone mention is that msdosfs has no concept of user 
or group, so "Can't set user=921/group=921 for ." makes perfect sense. 

Your 'ls -al' above showing "root wheel" indicates permissions related 
to the mount point.  If you'd mounted it as a normal user it could show 
"user user" ownerships, unrelated to what msdosfs stores on the disk. 
Similarly, mount_msdosfs(8) -u, -g and -m switches don't affect what's 
written to the disk, but only how the filesystem appears to FreeBSD.

For example, a 'cp -pR /etc /mnt/usb" also complains about not being 
able to set the ownership or permissions (other than DOS' read-only 
attribute) on target files, but it will still copy them ok, including 
filenames with spaces - but not with '&,+' or other non-DOS characters.

So maybe tar gives up before writing, because the ownership is wrong?

Perhaps the -o and -p options to tar(1) might help here, but the bottom 
line is that msdosfs is not really a suitable target for UFS files.  I 
tend to use zip(1)  - which keeps perms and ownership, though not hard 
links - to stash dirs and files on msdosfs, but format flash disks - or 
at least one or more slices on them - as UFS for real backup purposes.

cheers, Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111107180715.U72449>