fluiday / macfuse

Automatically exported from code.google.com/p/macfuse
Other
0 stars 0 forks source link

Strange behavior on not so long mount-paths (longer than 92 symbols) #149

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Open HelloFS project
2. Change mount point in Info.plist file to a sufficiently long one. For 
example "/tmp/zzzzzzzzzzzz this is not very long mount point 
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"
3. Be sure filesystem works (my own FS works improperly in this case), but 
NO new volume appears in Finder!

What version of the product are you using? On what operating system?
  MacFUSE 2.3
  System Version:   Mac OS X 10.4.9 (8P2137)
  Kernel Version:   Darwin 8.9.1

Original issue reported on code.google.com by pribam...@gmail.com on 21 Apr 2007 at 3:19

GoogleCodeExporter commented 9 years ago
Looks like an Apple issue. Keep MacFUSE out of the picture and mount something 
(say, a disk image or a USB 
keyfob) on a long (> 90 chars) mount path in your example. Then, try to unmount 
it:

$ unmount /tmp/zzzzzzzz....zzz
umount: unmount(/private/tmp/
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz): 
No such file or 
directory

At least one problem I see is that there's a buffer involved that's 90 
characters in length. See "man getfsstat" 
and look for MNAMELEN. If you call the unmount() system call directly, that 
should work. See also "man statfs", 
which also has a 90 character buffer for the name of the directory on which you 
mounted. Since the umount 
command uses getmntinfo(3), which uses statfs(2), unmount has this problem. 
Others programs that use one 
or more of these calls will have the same issue.

Original comment by si...@gmail.com on 23 Apr 2007 at 11:15

GoogleCodeExporter commented 9 years ago

Original comment by si...@gmail.com on 27 Apr 2007 at 7:36