re: GRASS FTP site

Hi!
  I cannot reproduce the FTP error some of you are describing using any of
our local machines, even PC's. Thus I would like to request the following
information from anyone experiencing FTP problems.

  1) Brand name and model of machine the fault occured on.
  2) Brand name of the OS on that machine. (ie SCO, EP/IX, etc)
  3) Version number of that OS you are using.
  4) Whether problems persist when you disable the advanced
      features of our FTP. (ie send "-" as the first char of
      your password)

Maybe I can find a common thread among your responses.

Thank you,

Russ Northrup
Systems Admin, US Army CERL

I confirm the troubles others have had too. Your **new** <MOON> didn't
recognice the "ls -l" command but "ls" did work normally...
That isn't the problem of our servers or OS etc.
The **old** <MOON> and the **older** <AMBER> worked very well!
---
BTW, we are working under UTek-V on TEK-88/34 and got the GRASS from <AMBER>.

F. Hoffmann, TU Dresden, Germany

rom lists-owner@max.cecer.army.mil Fri Sep 18 09:00:32 1992
Received: from zorro.cecer.army.mil by amber.cecer.army.mil (4.1/SMI-4.1)
  id AA00366; Fri, 18 Sep 92 09:00:32 CDT
Received: from amber.cecer.army.mil by zorro.cecer.army.mil with SMTP id AA01075
  (5.67a/IDA-1.4.4 for <grassu-people@amber.cecer.army.mil>); Fri, 18 Sep 1992 09:00:29 -0500
Return-Path: <courtney@agcrr.bio.ns.ca>
Received: from max.cecer.army.mil by amber.cecer.army.mil (4.1/SMI-4.1)
  id AA00360; Fri, 18 Sep 92 09:00:17 CDT
Received: from agcrr.BIO.ns.ca by max.cecer.army.mil with SMTP id AA19628
  (5.67a/IDA-1.5 for <grassu-list@max.cecer.army.mil>); Fri, 18 Sep 1992 09:00:13 -0500
Received: by agcrr.bio.ns.ca (5.57/Ultrix3.0-C)
  id AA02970; Fri, 18 Sep 92 11:01:03 -0300
Date: Fri, 18 Sep 92 11:01:03 -0300
From: courtney@agcrr.bio.ns.ca (Bob Courtney)
Message-Id: <9209181401.AA02970@agcrr.bio.ns.ca>
Sender: lists-owner@max.cecer.army.mil
Reply-To: grassu-list@max.cecer.army.mil
Precedence: Bulk
To: grassu-list@max.cecer.army.mil
Subject: re: r.in.sunrast AGAIN
Cc: courtney@agcrr.bio.ns.ca

Helpful suggestions for the fix to r.in.sunrast have been offered
by :

Jim Hinthorne,
Director GIS Lab
Central Wash. Univ.

He pointed out that :

Two more changes are needed to make this program bullit-pruff.

1. The parameter passed to G_malloc should be ncol_fix, not ncols,
because this is the size of the record to read later.

2. Before the final "return 1;" there should be "free (raster);" so
that the space allocated by G_malloc will be freed up. Some systems
are good about doing this automatically when the program exits, but
some aren't so friendly and the programmer should take responsibility
for freeing allocated memory.

So, the new fix to r.in.sunrast would be :

...........................................................

cd src.alpha/raster/r.in.sunrast/cmd

and edit main.c

replace the function rasttocell with :

rasttocell (rast_fd, cell_fd, nrows, ncols)
{
    unsigned char *raster;
    CELL *cell;
    int row, col, ncol_fix ;

    /* check if row is even or odd */
    ncol_fix = ncols;
    if ( ncols % 2 )
           ncol_fix += 1 ;

    cell = G_allocate_cell_buf();

    /* JH fix 1 */
    raster = (unsigned char *) G_malloc(ncol_fix);

    if (verbose)
        fprintf (stderr, "complete ... ");
    for (row = 0; row < nrows; row++)
    {
        if (verbose)
            G_percent (row, nrows, 2);
        if (read (rast_fd, raster, ncol_fix) != ncol_fix)
            return -1;
        for (col = 0; col < ncols; col++)
            cell[col] = (CELL) raster[col];
        if (G_put_map_row (cell_fd, cell) < 0)
            exit(1);
    }

    if (verbose)
        G_percent (row, nrows, 2);

    /* JH Fix 2 */
    free (raster);
    return 1;
}

and recompile

...........................................................

Thanks, Jim

Bob Courtney
Atlantic Geoscience Centre