Using the Macfile Utility

[Previous] [Next]

If you prefer to use a command-line utility to manage your servers, you're in luck—Windows 2000 includes an updated version of the Macfile utility included with Windows NT 4. Macfile provides a command-line interface that lets you manage FSM servers, MAVs, users, and files from a Windows 2000 command shell. Like the venerable Net User command, Macfile grows on you once you get used to it, because it makes short work of many common administrative tasks. Macfile actually has four separate functions:

• Macfile Server lets you manage server-related settings, including the number of sessions your server will support, whether guests are allowed to log on or not, and what message is displayed to users at logon.
• Macfile Volume allows you to create and remove MAVs and to set properties on the MAVs already on your server.
• Macfile Directory allows you to set owner, user, and group permissions on a MAV, using Macintosh-like specifiers.
• Macfile Forkize is the odd man out—it's used for manipulating the data and resource forks of a Macintosh file on a MAV. It also has some additional switches that let you change the type and creator of a file or group of files.

Using Macfile Server

The Macfile Server command lets you work with the same settings as the Configuration tab of the File Server For Macintosh Properties window you saw earlier in Figure 22-8. Here's the full version of the command:

 MACFILE SERVER [/SERVER:\<I>computername] [/MAXSESSIONS:number  | UNLIMITED] [/LOGINMESSAGE:message] [/GUESTSALLOWED: TRUE | FALSE] 

• The /SERVER flag lets you specify which server your changes apply to. If you leave it off, FSM assumes that you're modifying options on the local server.
• The /MAXSESSIONS switch lets you specify a limit on the number of current sessions you want your server to support.
• The /LOGINMESSAGE switch lets you change the logon message displayed to users. Enclose your message in double quotes and keep it to fewer than 255 characters.
• The /GUESTSALLOWED switch lets you specify whether your server will accept guest connections or not, subject to the limitations and caveats presented earlier in the chapter.

Using Macfile Volume

If you want to add, remove, or reconfigure a MAV, the Macfile Volume command is the tool to use. This command actually has three separate modes, each triggered by its own command switch.

The Macfile Volume /Remove Command

The least complex variant of Macfile Volume is the one that lets you remove existing MAVs. This isn't surprising, since removing a volume requires only that you specify the MAV you want removed (and, optionally, the server that hosts it). Here's what the command looks like:

 MACFILE VOLUME /REMOVE [/SERVER:\<I>computername] /NAME:volumename 

• The /SERVER switch lets you supply the name of the FSM server that hosts the volume you want to remove. If you don't specify a name, the command assumes you're removing a MAV from the local server.
• The /NAME switch is how you specify the MAV to remove. To remove a MAV whose name contains embedded punctuation or spaces, enclose the name in double quotes.

The Macfile Volume /Add Command

Adding a volume is pretty easy. When you create a new MAV using the Shared Folder Wizard, you provide settings as described earlier in this chapter. The only required settings are the name you want the MAV to have and the path to the folder the MAV sits on—and so it is with Macfile Volume /Add. The full version of the command is shown below. (Note that the /SERVER and /NAME switches work the same as they do with Macfile Volume /Remove.)

 MACFILE VOLUME /ADD [/SERVER:\<I>computername] /NAME:volumename /PATH:filepath [/READONLY:TRUE|FALSE] [/GUESTSALLOWED:TRUE|FALSE] [/PASSWORD:password] [/MAXUSERS:number|UNLIMTED] 

• /PATH specifies the full path, including the drive letter, of the folder you want to share as a MAV. This folder cannot be inside a folder or volume that's already shared as a MAV.
• /READONLY controls whether FSM treats this volume as read-only or not. This has the same effect as the This Volume Is Read-Only check box in the MAV Properties window; as with that check box, the default setting for this switch is FALSE.
• /GUESTSALLOWED controls whether guests may log on to this MAV or not. It's identical to the Guests Can Use This Volume check box; the default value is TRUE.
• /PASSWORD specifies a volume password, as described in the section "Volume Passwords" earlier in this chapter. By default, no password is assigned when you create a volume.
• /MAXUSERS governs the maximum number of concurrent users allowed to use this MAV. The default setting doesn't impose a limit (like the Maximum Allowed option in the MAV Properties window), but you can specify a numeric limit here.

The Macfile Volume /Set Command

The Macfile Volume /Set command lets you change the settings supplied when you created the MAV; you can toggle its read-only status, specify whether guests may use it or not, set the volume password, and indicate how many users can use the MAV. The syntax is very similar to that needed for the /Add switch:

 MACFILE VOLUME /SET [/SERVER:\<I>computername] /NAME:volumename [/READONLY:TRUE|FALSE] [/GUESTSALLOWED:TRUE|FALSE] [/PASSWORD:password] [/MAXUSERS:number|UNLIMITED] 

Using Macfile Directory

The name Macfile Directory is a little misleading; Macfile Permissions might have been a better choice, since you use the command to assign permissions to a directory within a MAV (or to the directory that contains the MAV). You can individually assign an owner, assign a group, or set permissions for the owner or group. The command is shown below (The /SERVER and /PATH switches work as previously discussed.)

 MACFILE DIRECTORY [/SERVER:\<I>computername] /PATH:directorypath [/OWNER:ownername] [/GROUP:groupname] [/PERMISSIONS:permsmask] 

• The /OWNER switch specifies what Windows 2000 account owns the MAV. This change applies to the actual directory for the MAV, and it's also reflected in the Sharing section of the Mac OS Info window for the MAV—both the Mac OS client and the FSM server see the change in ownership.
• The /GROUP switch changes the primary group that has Mac OS permissions for the MAV. Since Mac OS clients can resolve permissions for only one group entry, you have to choose which of the Windows 2000 group permissions is primary. Groupname can be the name of any valid Windows 2000 group, whether it's local or stored in the domain directory.
• The /PERMISSIONS switch accepts as its argument an 11-digit bit mask that specifies, bit by bit, which permissions you want to apply to the MAV in question. Table 22-1 shows what the bits in the mask mean; for each position in the mask, a value of 1 means the permission is turned on, and a value of 0 means it's off.

Table 22-1. What the bits in the /PERMISSIONS mask field mean

Bit Position	Meaning
1 (leftmost)	OwnerSeeFiles: 1 = the owner can see files in the folder; 0 = the owner can't see the files.
2	OwnerSeeFolders: 1 = the owner can see enclosed folders; 0 = the owner can't see the folders.
3	OwnerMakeChanges: 1 = the owner can make changes to the files and folders; 0 = the owner can't make changes.
4	GroupSeeFiles: 1 = members of the primary group can see files in the folder; 0 = members of the primary group can't see the files.
5	GroupSeeFolders: 1 = members of the primary group can see enclosed subfolders; 0 = members of the primary group can't see the subfolders.
6	GroupMakeChanges: 1 = members of the primary group can make changes to the files and folders; 0 = members of the primary group can't make changes.
7	WorldSeeFiles: 1 = Everyone can see files in the folder; 0 = Everyone can't see the files.
8	WorldSeeFolders: 1 = Everyone can see enclosed subfolders; 0 = Everyone can't see the subfolders.
9	WorldMakeChanges: 1 = Everyone can make changes to the files and folders; 0 = Everyone can't make changes.
10	Cannot Rename, Move, or Delete: Setting this bit to 1 is the same as locking the folder on the Mac OS side.
11 (rightmost)	Apply Changes Recursively: When this bit is set, the rest of the permissions mask you specify will be applied to all subfolders of the target folder. This is the equivalent of the standard Windows 2000 permission inheritance behavior.

NOTE

---

You must specify either the /OWNER, /GROUP, or /PERMISSIONS switches when you use Macfile Directory.

With one exception (when you turn on bit 11 in the mask for the /PERMISSIONS switch), none of these changes are applied recursively.

Using Macfile Forkize

The remaining command, Macfile Forkize, is much like a Swiss Army knife—it has several useful functions that aren't needed often but that are occasionally really handy. You use Macfile Forkize to do two things: change the type or creator code for a file or combine the resource and data forks of a file. Here's the command syntax:

 MACFILE FORKIZE /TARGETFILE:filepath [/SERVER:\\computername] [/TYPE:typecode] [/CREATOR:creatorcode] [/DATAFORK:filepath] [/RESOURCEFORK:filePath] 

• The /TARGETFILE switch designates the full path to the file you want to forkize. If you're combining a data and resource fork, /TARGETFILE specifies where the resulting file goes. If you're changing a type or creator, it specifies where the file to be modified is currently located. As always, paths that contain special characters or spaces must be enclosed in double quotes.
• The /TYPE and /CREATOR switches let you specify the four-character type and creator codes for a particular file. For example, to change a single file so that its type is TEXT and its creator code matches the code for Macromedia's Dreamweaver, you'd use this command:

 macfile forkize /targetfile:f:\shared\html\welcome.htm / type:TEXT /creator:DmWr 

This is a quick way to fix up types and creators of existing files after you change the associations using the methods described earlier in this chapter (except that you can't use wildcards with the /TARGETFILE switch, so you'll need another way to process multiple files, like a short Windows Scripting Host [WSH] script).

• The /DATAFORK and /RESOURCEFORK switches specify the locations of the files whose forks you want to join. FSM doesn't do any checking as to whether your request makes sense or not, so there's nothing stopping you from welding the resource fork of Microsoft Word 98 for the Macintosh onto the data fork of a document (for example).