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 TAA09348
	for <Thomas.Kaiser@phg-online.de>; Sat, 24 Nov 2001 19:34:15 +0100
Received: from lists.apple.com (localhost [127.0.0.1])
	by lists.apple.com (8.11.6/8.11.6) with ESMTP id fAOHvqb24103;
	Sat, 24 Nov 2001 09:57:52 -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
  fAOHfFd23104 for <macos-x-server@lists.apple.com>; Sat, 24 Nov 2001
  09:41:15 -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
  TAA09254; Sat, 24 Nov 2001 19:02:33 +0100
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106
Subject: Re: Essential CLI Tools for MacOS X (was: Re: Thank you for
  help with NAT)
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: <B825A12D.15128%Thomas.Kaiser@phg-online.de>
In-Reply-To: <Pine.GSO.4.33.0111241011170.17127-100000@cs.usm.my>
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: Sat, 24 Nov 2001 19:10:37 +0100
X-UIDL: 44cb364a39cd07888f7e6d5fbc3e22db

On Sat, 24 Nov 2001 10:23:22 +0800 (SGT), Wan Tat Chee wrote:

> I welcome constructive comments, especially corrections/additions.

Good job! Thanks.

Okay, then let's start:

Have you thought about explaining the different path separators ":" and "/"?
The Finder will display colons, used on UFS partitions, always as slash. On
the unix side filenames on HFS+ partitions, containing a slash will be
mangled to contain a colon...

Also the permissions situation on hfs+ file systems.
(see also /Developer/Documentation/ReleaseNotes/Permissions.html)

> Manipulating Carbon/Classic Files
> 
> *    Use the Finder (easiest, pain-free)
> *    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.

> *    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?

> *    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

> *    ditto (from /usr/bin), to copy an entire directory hierarchy

IMHO, you should mention the "-rsrc" switch.

> *    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:

     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.

- On hfs+ and afpfs filesystems this will result in loss of Finder infos
 
> *    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)

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?

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

Regards,

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