Return-Path: <macos-x-server-admin@lists.apple.com>
Received: from lists.apple.com (lists.apple.com [17.254.0.151])
	by users.phg-online.de (8.9.3/8.9.3) with ESMTP id OAA25193
	for <Thomas.Kaiser@phg-online.de>; Sun, 25 Nov 2001 14:12:20 +0100
Received: from lists.apple.com (localhost [127.0.0.1])
	by lists.apple.com (8.11.6/8.11.6) with ESMTP id fAPCflb08515;
	Sun, 25 Nov 2001 04:41:47 -0800 (PST)
Received: from users.phg-online.de (users.phg-online.de
  [62.245.158.230]) by lists.apple.com (8.11.6/8.11.6) with ESMTP id
  fAPCUwd07823 for <macos-x-server@lists.apple.com>; Sun, 25 Nov 2001
  04:30:59 -0800 (PST)
Received: from [195.30.238.157] (powerbook-tk.kaiser.link-m.de
  [195.30.238.157]) by users.phg-online.de (8.9.3/8.9.3) with ESMTP id
  NAA25148; Sun, 25 Nov 2001 13:52:52 +0100
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106
Subject: Re: Essential CLI Tools for MacOS X
From: Thomas Kaiser <Thomas.Kaiser@phg-online.de>
To: Wan Tat Chee <tcwan@cs.usm.my>
CC: <macos-x-server@lists.apple.com>
Message-ID: <B826AA19.15168%Thomas.Kaiser@phg-online.de>
In-Reply-To: <B825A12D.15128%Thomas.Kaiser@phg-online.de>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: macos-x-server-admin@lists.apple.com
Errors-To: macos-x-server-admin@lists.apple.com
X-BeenThere: macos-x-server@lists.apple.com
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:macos-x-server-request@lists.apple.com?subject=help>
List-Post: <mailto:macos-x-server@lists.apple.com>
List-Subscribe: <http://www.lists.apple.com/mailman/listinfo/macos-x-server>,
	<mailto:macos-x-server-request@lists.apple.com?subject=subscribe>
List-Id: for administrators of Mac OS X Server and related technologies. <macos-x-server.lists.apple.com>
List-Unsubscribe: <http://www.lists.apple.com/mailman/listinfo/macos-x-server>,
	<mailto:macos-x-server-request@lists.apple.com?subject=unsubscribe>
List-Archive: <http://www.lists.apple.com/archives/macos-x-server/>
Date: Sun, 25 Nov 2001 14:00:58 +0100
X-UIDL: 760c47bc56dad4f649b42cb8b744bbae

On Sat, 24 Nov 2001 19:10:37 +0100, Thomas Kaiser wrote:

Sorry, I'm back again. Played a bit around and found other problems arising.
My intereset in MaxOS X Server is to use it as a stable fileserver for Mac
and Windows clients (at the moment I'm using Helios' EtherShare, so I demand
a great deal of a multi-plattform fileserver ;-). As a consequence, I put my
focus on things like afp conformance, persistent file- and directory ids and
what the clients have to expect after moving files around on the server
(same with creation/deletion of files/folders).

> On Sat, 24 Nov 2001 10:23:22 +0800 (SGT), Wan Tat Chee wrote:
>
>> Manipulating Carbon/Classic Files
>> 
>> *    Use the Finder (easiest, pain-free)

That's not true either. If you use the Finder on a client mac to copy a file
from one of your server's volumes to another, it will only work, if they
both use the same filesystem (please note: MacOS X Server supports the
SupportsCopyFile Bit, which will result in less network traffic when you
attempt to copy from one server volume to another --> the server will be
asked to do the job for you, so that the file won't be transferred over the
wire at all). 

In the case you copy from one hfs volume to an ufs volume, the Finder will
stop, saying "object is in use". On the UNIX side you can see an empty
datafork, an empty ressource fork, the latter owned by 'root'! Looks like
ditto is used on the server (see above)

The only way to do so, is to copy the file from one server volume to your
local harddisk and then back to the other volume.

Another restriction is the loss of Finder comments when copying files
between volumes (when using the "SupportsCopyFile" trick)! Seems to be only
a problem for afp clients since MacOS 10 stores Finder comments different
for local use than for afp clients?

>> *    For filenames containing spaces, the filename can be quoted (e.g.,
>>      "filename with space") or the Unix escape character '\' followed by a
>>      space can be used (e.g., filename\ with\ space). Easiest is to let the
>>      shell filename completion feature (tab) do it for you.
>> *    Listing Files:
>> *    ls -al (from /bin) to show standard Unix attributes (drwx), owner and
>>      group, and file sizes
> 
> /Developer/Tools/GetFileInfo in conjunction with e.g. ls can be used to look
> at HFS attributes, FileType and Creator and also the file's creation dates.

But no way to get/set Finder comments?

>> *    Copying Files:
>> *    CpMac (from Developer's Tools CD, under /Developer/Tools)
> 
> CpMac did a bad job in 10.1. When copying a file, the ressource fork got
> wrong ownership and permissions. Looks like this has been fixed? (I believe
> CpMac calls some Libraries which have been updated silently in 10.1.1)
> 
>> *    macbin (from /usr/bin), which converts HFS files to MacBinary format,
>>      used in the following sequence
> 
> I have a plain vanilla MacOS X 10.1(.1) installation. No macbin around.
> Where did you get yours from?

Okay, found it (looked on a MacOS X client machine erroneous yesterday)

Macbin is pretty useless to do file operations on the server if the
filesystem of the source file isn't hfs+ or afpfs (doesn't honor the
resource fork at all). Otherwise it will do a good job (when updated to
10.1.1 before), all HFS attributes will be retained, even Finder labels :-)

>> *    macbin -e {filename} > {filename}.bin; cp {filename}.bin {destination
>>      directory}; cd {destination directory}; macbin -d < {filename}.bin
> 
> Have you tried it in one single step:
> 
> cd {destination directory}; macbin -e {/path/filename} | macbin -d

This will work (exception above)

>> *    ditto (from /usr/bin), to copy an entire directory hierarchy
> 
> IMHO, you should mention the "-rsrc" switch.

One exception: When using ditto to copy to a filesystem other than hfs+ or
afpfs and this filesystem owned by root, then the resource fork will be
owned by the user that copied. If ditto will be used by root, the data
fork's ownership remains unchanged, which will result in situations like
this:

-rw-r--r--   1 root   wheel      6424 Sep 22 01:28 ._new-image.jpg
-rw-r--r--   1 tk     staff     42705 Sep 22 01:28 new-image.jpg

>> *    Moving Files/Directories:
>> *    mv (from /bin) [Note: I think this'll only work correctly if it's on the
>>      same partition]
> 
> If source and target are not on the same partition, mv will behave like cp
> and rm.
> 
> man rm:

Upps. 'man mv' would be better ;-)

>   As the rename(2) call does not work across file systems, mv uses cp(1)
>   and rm(1) to accomplish the move.  The effect is equivalent to:
> 
>       rm -f destination_path && \
>       cp -PRp source_file destination && \
>       rm -rf source_file
> 
> When using mv acrross file system boundaries (same with plain 'cp'):
> 
> - On filesystems other than hfs+ and afpfs, mv will transport HFS attributes
>   correctly as long as you move both forks together.

But File-/Folder-IDs will get corrupted. Under some circumstances myterious
things will happen from the afp client's perspective.

> - On hfs+ and afpfs filesystems this will result in loss of Finder infos

As expected as mv will invoke cp (stone-blind for resource forks) in these
situations.

>> *    Deleting Files [Note: see 'Changing HFS attributes' and 'Changing Unix
>>      attributes' if operation fails]:
>> *    rm (from /bin)
> 
> Deleting the ressource forks too on UFS, SMBFS, etc., should be recommended.
> Otherwise strange effects may occur, when an orphaned RessourceFork has bad
> permissions/ownership, so the Finder can't copy a file with the same name
> into this directory. Joe User will never find out why cause the Finder gives
> not a very proper explanation ("wrong permissions"). The datafork will be
> written with 0 bytes and the file itself will be visible in the finder
> (using the PICT ressources inside the old ressourcefork). Joe User will
> probably think everything went right (ignoring the error message) but --
> surprise -- will find out later, that the file itself is entirely damaged.
> 
> -rw-r--r--   1 root  wheel  52703 Nov 24 17:01 ._new-image.jpg
> -rw-r--r--   1 tk    wheel      0 Nov 24 17:59 new-image.jpg
> 
>> *    rm -Rf {directory}, to delete an entire directory.
>>      [Careful! There is no 'undelete', don't use wildcards unless you're
>>      absolutely sure of what you're doing]
>> 
>> 
>> *    Changing HFS attributes [Note: HFS attributes are not shown by 'ls
>>      -al']:
>> *    chflags (from /usr/bin/)
>> *    chflags -R nouchg {files or directories}, if files can't be deleted
>>      [Also, refer Apple Knowledge Base #106272]
>> 
>> *    SetFile (from Developer's Tools CD, under /Developer/Tools)
> 
> SetFile can also be used to modify FileType and Creator and the creation
> time of a File/Folder.
> 
>> *    Changing Unix attributes:
>> *    chmod (from /bin), to set/clear owner, group and others rwx permissions
>> *    chown (from /usr/sbin), to change current owner and group to another
> 
> You should also mention to always modify both data and resource forks on non
> filesystems other than hfs+ and afpfs. Otherwise mysterious things will
> happen.
> 
> One could do this in a simple replacement for both tools checking for the
> existence of "`basename $filename`"._"`filename $filename`" and handling
> both forks together (same with mv and rm above)

Well, after playing a bit around with this stuff, I would suggest, to never
ever handle files from the command line unless the volume is hfs+ and you
are not moving files across file system boundaries.

For now, Apple doesn't provide us with tools suitable for handling files
from within UNIX-Scripts or from the command line.

>From my short experience with volumes other than hfs+ shared via afp, I
believe, everything you do from unix will lead to corrupted file-/directory
ids (your aliases will point elsewhere but not to the original file, for
example). This might confuse other applications as well, e.g. xpress.

> BTW: Has anybody had experiences with wrong file and/or folder IDs when
> sharing ufs partitions via afp (trouble with quark xpress for example)?
> I wonder how /usr/sbin/AppleFileServer can handle those IDs on filesystems
> that don't support ids at all?

The questions still remain...

> Is there a tool, that is able to display the IDs (on the server or remote
> from an afp client)?

This would be very helpful to nail the problems down or just to understand
what's happening in which case (remote file access, local file handling via
CLI)

Amongst other things (like case-sensitivity issues which will make
backup/restore between partitions using different formats possibly a
nightmare) the misbehaviour of the file handling utilities packaged with
MacOS X Server makes it a good idea to not mix ufs and hfs partitions if you
want to share them. As some of the the tools lack essential support for ufs
it might also be a better idea to use hfs+. But I won't entrust my data to a
filesystem which is known to destroy itself from time to time ;-)

Apologies for these frustrating statements. But I'm testing a beta of
Helios' EtherShare for MacOS X also, and there I can handle all the file
stuff without problems either directly on the server from the command line
(using the so called 'desktop utilities', a set of replacements for the unix
commands rm, rmdir, mv, cp, ls, mkdir, touch, chmod, chown and chgrp) or
remote from mac or win clients, without having to worry about corrupted
file-/directory-ids, wrong permissions/ownerships, etc. Well, they call it a
beta... but it works like a charm compared to... ahem... ;-)

Regards,

Thomas
_______________________________________________
macos-x-server mailing list
macos-x-server@lists.apple.com
http://www.lists.apple.com/mailman/listinfo/macos-x-server