NCSA Home
Contact Us | Intranet | Search

MSS Tricks


How can I retrieve the first 200 lines of a file from MSS?

    Suppose you want to get the first 200 lines of bigFile and put it into a local file called smallFile. From an NCSA production machine, issue the command:
    msscmd 'get  bigFile  "| head -200 >  smallFile"'
    
    In FTP, issue the command:
    ftp> get bigFile "| head -200 > smallFile"
    
    With SSH:
    ssh your_login@mss.ncsa.uiuc.edu "head -200 bigFile" > smallFile
    

Every time I use msscmd, I execute the same initial sequence of commands (e.g. umask 077, verbose, etc). Is there a way to do this automagically?

    Yes, create a file called .msscmdrc in your home directory with the initial sequence of commands you always execute. This file .msscmdrc is read upon every invocation of msscmd and the commands in this file are executed prior to any commands you issue after msscmd.

How can I preserve the creation time of my files?

    When I retrieve files from MSS the timestamp is the current time and not the time the file was created. The unix utility "tar" preserves the timestamp of files. See the tar man page for more information.

    The option to preserve timestamps with secure copy transfers:

    scp -p

How can I create a symbolic link in MSS?

    The FTP command:
    ftp> quote ln file1 file2
    
    and the SSH command:
    ln -s file1 file2
    
    both make file2 point to file1

Do wildcards work with a kerberized FTP client?

    The commands mget, mput, mdelete all work with wildcards, but mchmod and mchgrp do not.

    Note: with a kerberized FTP session, you can issue the command "prompt". This command toggles the prompting option off (asking to confirm each download). By default, kerberized FTP connections have the prompt option on.

Why does the `du` command in the SSH interface show me lower disk usage than I expect?

    The main reason is because it overlooks "holes" in the filesystem corresponding to data that resides only on MSS tape. Using the --apparent-size option will cause `du` to report accurate values for archived data.

    A second reason would be that it reports block usage instead of byte usage by default. Get it to use bytes with the -b option.

    Other helpful options are:

      -h, --human-readable  print sizes in human readable format (e.g., 1K 234M 2G)
      -S, --separate-dirs   do not include size of subdirectories
    
    So to get an easily interpreted summary of how much data is located in an MSS directory use:
    du -sh --apparent-size directory