Odd problem with find(1) on FUSE sshfs mounted filesystems

[Kimmo Paasiala]

On 13.6.2014, at 9.49, Kimmo Paasiala <kpaasial at icloud.com> wrote:

> I’m on FreeBSD stable/10 r267390 on one of my systems and on FreeBSD 10.0-RELEASE-p5 i386 on another one. Both exhibit a strange behaviour when find(1) is used on a FUSE sshfs mounted filesystems. This an excerpt of a log from such run (I mounted FreeBSD sources on /mnt using sshfs):
> 
> ...
> mnt/contrib/ofed/libmlx4/autogen.sh^M
> /mnt/contrib/ofed/libmlx4/mlx4.driver^M
> /mnt/contrib/ofed/libmlx4/config^M
> /mnt/contrib/ofed/libmlx4/Makefile.am^M
> /mnt/contrib/openresolv^M
> find: /mnt/contrib/openresolv/pdnsd.in: No such file or directory^M
> find: /mnt/contrib/openresolv/resolvconf.8.in: No such file or directory^M
> find: /mnt/contrib/openresolv/resolvconf.conf.5.in: No such file or directory^M
> find: /mnt/contrib/openresolv/configure: No such file or directory^M
> find: /mnt/contrib/openresolv/unbound.in: No such file or directory^M
> find: /mnt/contrib/openresolv/named.in: No such file or directory^M
> find: /mnt/contrib/openresolv/resolvconf.conf: No such file or directory^M
> find: /mnt/contrib/openresolv/dnsmasq.in: No such file or directory^M
> find: /mnt/contrib/openresolv/Makefile: No such file or directory^M
> find: /mnt/contrib/openresolv/libc.in: No such file or directory^M
> find: /mnt/contrib/openresolv/README: No such file or directory^M
> find: /mnt/contrib/openresolv/resolvconf.in: No such file or directory^M
> find: /mnt/contrib/openresolv: No such file or directory^M
> /mnt/contrib/ntp^M
> …
> 
> 
> I can rsync(1) the files from the mounted filesystem just fine without any errors/corruption so clearly all the files and directories are there and accessible. 
> 
> Is this a problem in FUSE/sshfs or find(1) and how to start debugging this?
> 
> I have tested with both FreeBSD and OS X as SSH servers and the same problem is present using both systems.
> 
> In all of the tests I’ve done there are no mountpoints crossed, each mounted directory tree is on a single filesystem on the server.
> 
> -Kimmo

No one else has seen this behaviour? I’d like to use sshfs as a secure and less complicated replacement for NFS but if I can’t trust it to work with standard utilities like find(1) I’ll have to pass for now.

-Kimmo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140615/0836b688/attachment.sig>