Re: msdosfs mask?

On Sun, 5 Oct 2003, Nate Lawson wrote:

> In the past, msdosfs has taken its permissions from the mountpoint.
> Recently I noticed that this still works for files in the root directory
> but subdirectories are all chmod 000.  Has anyone else seen this?  Adding
> the -m=755 flag for instance does work for the files in the top of the
> mountpoint (i.e. command.com) but not subdirectories, which are still 000.
> What's going on?

This still works for me.

Perhaps your mount_msdosfs binary is out of date.  Rev.1.25 of
mount_msdosfs.c is required to keep up with corresponding kernel
changes.  It passes a separate mask for directories.  Old versions of
mount_msdosfs don't understand the new field for the directory mask
in the args struct so they don't pass anything.  More precisely, it
happens that the new field fits in unnamed padding in the old args
struct, so adding it didn't completely break binary compatibility
with old mount_msdosfs binaries; all version fill memset the struct
to 0 so they set unnamed padding to 0, so old versions do the equivalent
of the new version when the latter is invoked with "-M 0".  But a mask
of 0 is rarely what is wanted.

The compatibility problems can be fixed easily since the new field is
in spare space and there is already a magic number and flags for version
control.

See also PR bin/57401 which has a quick fix for amd.  The fix is wrong
since it is under a wrong ifdef, and it shouldn't be necessary -- amd
should work like an old mount_msdosfs binary and simply not pass a
dirmask (by not setting a flag which that it passes one).  amd could
also use flags for saying that it doesn't pass a file mask or uid or
gid...  either.  It always passes 0777 for the file mask and 0 for the
ids instead of the attributes inherited from the mount point.  Perhaps
more of the logical for this should be in the kernel since applications
get it wrong.

Bruce