I am trying to backup a Windows-hosted share, using rsync, from a FreeBSD8.2 box:
That is, I correctly see folders with Greek characters (locale-specific). The listing above is from a PuTTY session (i.e. an SSH session), and PuTTY was configured to translate UTF-8 by default.
Note I have not touched the locale:
So all seems to be OK.
However, when I tried rsyncing from the mounted folder, some files appear to vanish...
The message "file has vanished" means that rsync called the proper system calls to read the contents of a folder (dir/dirent I believe), and when it later tried to read one of the contained files, it did not find it - i.e. "open(2)" failed.
I checked the reported file: (a) it exists, (b) it has world-readable permissions.
I then assumed that the cp737 (Greek codepage) is the problem, so I mounted again with...
...that is, I used utf-8 for the Windows side, too. When I tried rsync again, however, it got stuck (!) with 100% CPU utilization... Attaching with GDB showed:
...so it initially appeared that rsync is stuck waiting for getdirentries to return, or that each call to getdirentries takes a lot of time...
Then I used...
...and it turns out that it's not just rsync - a simple find is also getting stuck, and truss reports...
As if somehow, both find and rsync end up reading from the same folder, over and over.
Any ideas?
Has anybody ever managed to do what I am doing? I.e. Use FreeBSD to rsync files with locale-specific characters in their filenames, from a Windows share that is mounted via mount_smbfs?
P.S. In case anyone wonders why I try to do this, the answer is simple: ZFS.
Code:
bash$ sudo -i
bash# uname -a
FreeBSD zeus.companyname.gr 8.2-RELEASE ...amd64
bash# cat /root/.nsmbrc
...
[MACHINENAME]
password=mysuperuncrackablepassword
bash# mount_smbfs -N -E utf-8:cp737 -I 192.168.0.2 //Administrator@machinename/f$ /iso1/
bash# ls -l -raw /iso1/prj/
ΠΡΟΕΤΟΙΜΑΣΙΑ ΔΕΔΟΜΕÎΩΠΠΑΡΕΛΘΟÎΤΩΠΕΤΩÎ
Πανεπιστήμιο - Î Ïοβολή, ΔημοσιότηταThat is, I correctly see folders with Greek characters (locale-specific). The listing above is from a PuTTY session (i.e. an SSH session), and PuTTY was configured to translate UTF-8 by default.
Note I have not touched the locale:
Code:
bash# locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=So all seems to be OK.
However, when I tried rsyncing from the mounted folder, some files appear to vanish...
Code:
bash# rsync --inplace -rltvxp /iso1/ /backups/backup-machinename/
sending incremental file list
file has vanished: "/iso1/prj/..."The message "file has vanished" means that rsync called the proper system calls to read the contents of a folder (dir/dirent I believe), and when it later tried to read one of the contained files, it did not find it - i.e. "open(2)" failed.
I checked the reported file: (a) it exists, (b) it has world-readable permissions.
I then assumed that the cp737 (Greek codepage) is the problem, so I mounted again with...
Code:
bash$ mount_smbfs -N -E utf-8:utf-8 -I 192.168.0.2 //Administrator@machinename/f$ /iso1/...that is, I used utf-8 for the Windows side, too. When I tried rsync again, however, it got stuck (!) with 100% CPU utilization... Attaching with GDB showed:
Code:
bash# gdb /usr/local/bin/rsync 3109
GNU gdb 6.1.1 [FreeBSD]
Attaching to program: /usr/local/bin/rsync, process 3109
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
0x0000000800709c0a in getdirentries () from /lib/libc.so.7...so it initially appeared that rsync is stuck waiting for getdirentries to return, or that each call to getdirentries takes a lot of time...
Then I used...
Code:
truss -d -s 255 find /iso1...and it turns out that it's not just rsync - a simple find is also getting stuck, and truss reports...
Code:
...
200.223900400 getdirentries(0x5,0x800a2e000,0x1000,0x800a2d068,0x0,0x0) = 196 (0xc4)
200.224160040 getdirentries(0x5,0x800a2e000,0x1000,0x800a2d068,0x0,0x0) = 196 (0xc4)
200.224394880 getdirentries(0x5,0x800a2e000,0x1000,0x800a2d068,0x0,0x0) = 196 (0xc4)
...As if somehow, both find and rsync end up reading from the same folder, over and over.
Any ideas?
Has anybody ever managed to do what I am doing? I.e. Use FreeBSD to rsync files with locale-specific characters in their filenames, from a Windows share that is mounted via mount_smbfs?
P.S. In case anyone wonders why I try to do this, the answer is simple: ZFS.