hi all:
i've installed the latest cygwin version on an XP pro sp1 box.
when running some of the demo data i'm finging theat i can create temp files with r.patch but when i go to display, i get the following error
WARNING:Fail of initial read of compressed file [k059 in andy]
mail: not found
WARNING: unable to open raster map [k059 in andy]
mail:not found
ERROR: Not able to open cellfile for [k059]
mail:not found
i've looked in the andy directory and it does appear to exist. large file in the cell directory k059 in the cats directory etc.
i'm stumped.
permission's problem in cygwin?
any suggestions would be appreciated.
thanx.
Andy Fraser wrote:
i've installed the latest cygwin version on an XP pro sp1 box.
when running some of the demo data i'm finging theat i can create temp
files with r.patch but when i go to display, i get the following error
WARNING:Fail of initial read of compressed file [k059 in andy]
mail: not found
WARNING: unable to open raster map [k059 in andy]
mail:not found
ERROR: Not able to open cellfile for [k059]
mail:not found
i've looked in the andy directory and it does appear to exist. large file
in the cell directory k059 in the cats directory etc.
i'm stumped.
permission's problem in cygwin?
It isn't due to permissions. The above error occurs when reading from
a file returns insufficient data (premature end-of-file) or incorrect
data.
The first step is to ensure that the Cygwin filesystem on which the
data resides is mounted in "binary" mode, and not in "text" mode.
If the filesystem was mounted in "text" mode, Cygwin will attempt to
perform LF/CRLF translation, which will corrupt the files; in this
case, you would need to start again, as any files which had been
generated would already be corrupt.
--
Glynn Clements <glynn.clements@virgin.net>
On Sun, Dec 08, 2002 at 11:42:12PM +0000, Glynn Clements wrote:
If the filesystem was mounted in "text" mode, Cygwin will attempt to
perform LF/CRLF translation, which will corrupt the files; in this
case, you would need to start again, as any files which had been
generated would already be corrupt.
Hmm, does Cygwin open all files opened via open() in binary mode? I
should think so. However, it seems we should add the "b" to all the
fdopen() calls in src/libes/gis/open.c. On *nix systems it makes
no difference, but it might make the difference on other systems.
--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler
Eric G. Miller wrote:
> If the filesystem was mounted in "text" mode, Cygwin will attempt to
> perform LF/CRLF translation, which will corrupt the files; in this
> case, you would need to start again, as any files which had been
> generated would already be corrupt.
Hmm, does Cygwin open all files opened via open() in binary mode? I
should think so.
Unfortunately, no. The file is opened in binary mode if you use the
(Cygwin specific) O_BINARY flag in the call to open(), or if the file
resides on a "filesystem" which was mounted in binary mode, or if
$CYGWIN contains "binmode". Otherwise, it is opened in text mode.
However, it seems we should add the "b" to all the
fdopen() calls in src/libes/gis/open.c. On *nix systems it makes
no difference, but it might make the difference on other systems.
That won't help in this particular case, as cell I/O doesn't use those
functions. More generally, unless we "port" the whole of GRASS to
Cygwin (i.e. use O_BINARY), the user will need to ensure that any
GRASS databases reside on a binary filesystem.
--
Glynn Clements <glynn.clements@virgin.net>
On Mon, Dec 09, 2002 at 04:13:28AM +0000, Glynn Clements wrote:
Eric G. Miller wrote:
> > If the filesystem was mounted in "text" mode, Cygwin will attempt to
> > perform LF/CRLF translation, which will corrupt the files; in this
> > case, you would need to start again, as any files which had been
> > generated would already be corrupt.
>
> Hmm, does Cygwin open all files opened via open() in binary mode? I
> should think so.
Unfortunately, no. The file is opened in binary mode if you use the
(Cygwin specific) O_BINARY flag in the call to open(), or if the file
resides on a "filesystem" which was mounted in binary mode, or if
$CYGWIN contains "binmode". Otherwise, it is opened in text mode.
Oh, I see. I guess the Cygwin folks must've had a good reason for this
decision. I'm not inclined to add O_BINARY hacks just for cygwin,
though I think some of the magic numbers in open.c could be replaced
by their appropriate symbolic constants O_RDONLY, O_WRONLY and O_RDWR;
even if they are 0, 1, and 2 everywhere...
--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler