Hi, ---snip--- {71} <FreeBSD 5.1-CURRENT> [M87:~netchild/FreeBSD/SystemOnCD] (62) root_at_ttyp0 # realpath work/SystemOnCD-1/usr/ports/distfiles |wc -c 79 {0} <FreeBSD 5.1-CURRENT> [M87:~netchild/FreeBSD/SystemOnCD] (63) root_at_ttyp0 # realpath /space/distfiles |wc -c 17 {0} <FreeBSD 5.1-CURRENT> [M87:~netchild/FreeBSD/SystemOnCD] (64) root_at_ttyp0 # mount -t unionfs -o -b /space/distfiles work/SystemOnCD-1/usr/ports/distfiles unionfs: /space/distfiles: File name too long {71} <FreeBSD 5.1-CURRENT> [M87:~netchild/FreeBSD/SystemOnCD] (65) root_at_ttyp0 # mount -t unionfs -o -b /space/distfiles /mnt ---snip--- The same happens with nullfs, but not with ntfs. I can't find a documented limitation in the man pages (expect ENAMETOOLONG in mount(2), but the name is shorter than 255 characters). I also can't find ENAMETOOLONG in /sys/fs/unionfs/* (as mount_unionfs returns EX_OSERR, so it isn't the mount_unionfs utility which rejects the mount). This is with a pre-statfs-changes current. Does this problem still exists in a recent current? If yes: where does this ENAMETOOLONG come from? Bye, Alexander. P.S.: I don't complain about the wrong path printed with the error, looking at the source makes it obvious why this happens and it's easy to fix this without help. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander _at_ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7Received on Thu Nov 20 2003 - 05:34:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC