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>