Certainly there can be more reasons why writing wouldn't work.
Like nfs down or wrong permission?
To help diagnosing this it might be helpful to give the filename
in the error message where writing was attempted.
I would replace the "(disk full?)" comment by
". You might want to check available disk space and write permissions."
On Fri, Aug 23, 2002 at 03:41:48PM +0200, grass@intevation.de wrote:
Update of /grassrepository/grass/src/imagery/i.ortho.photo/photo.rectify
In directory doto:/tmp/cvs-serv27714
Modified Files:
write.c
Log Message:
made error message a bit more useful
- G_fatal_error("error while writing to temp file");
+ G_fatal_error("error while writing to temp file (disk full?)");
- G_fatal_error("error while writing to raster file");
+ G_fatal_error("error while writing to raster file (disk full?)");
unlink(temp_name);
On Fri, Aug 23, 2002 at 03:49:46PM +0200, Bernhard Reiter wrote:
Certainly there can be more reasons why writing wouldn't work.
Like nfs down or wrong permission?
that's right.
To help diagnosing this it might be helpful to give the filename
in the error message where writing was attempted.
I would replace the "(disk full?)" comment by
". You might want to check available disk space and write permissions."
submitted. thanks.
Markus
On Fri, Aug 23, 2002 at 03:41:48PM +0200, grass@intevation.de wrote:
> Update of /grassrepository/grass/src/imagery/i.ortho.photo/photo.rectify
> In directory doto:/tmp/cvs-serv27714
>
> Modified Files:
> write.c
> Log Message:
> made error message a bit more useful
> - G_fatal_error("error while writing to temp file");
> + G_fatal_error("error while writing to temp file (disk full?)");
> - G_fatal_error("error while writing to raster file");
> + G_fatal_error("error while writing to raster file (disk full?)");
> unlink(temp_name);
--
Markus Neteler
ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
Project on Predictive Models for the Environment
Via Sommarive, 18 - 38050 Povo (Trento), Italy
tel +39 0461 314 -520 (fax -591) http://mpa.itc.it
On Fri, Aug 23, 2002 at 03:59:18PM +0200, Markus Neteler wrote:
On Fri, Aug 23, 2002 at 03:49:46PM +0200, Bernhard Reiter wrote:
> To help diagnosing this it might be helpful to give the filename
> in the error message where writing was attempted.
> I would replace the "(disk full?)" comment by
> ". You might want to check available disk space and write permissions."
submitted. thanks.
It may be even nice to see *which* partition is full.
At least here it's difficult, we have a complicated mixture
of NFS linked machines with lot's of partitions. Is there
a portable method to print which partition is full?
Markus
> On Fri, Aug 23, 2002 at 03:41:48PM +0200, grass@intevation.de wrote:
> > Update of /grassrepository/grass/src/imagery/i.ortho.photo/photo.rectify
> > In directory doto:/tmp/cvs-serv27714
> >
> > Modified Files:
> > write.c
> > Log Message:
> > made error message a bit more useful
>
> > - G_fatal_error("error while writing to temp file");
> > + G_fatal_error("error while writing to temp file (disk full?)");
>
> > - G_fatal_error("error while writing to raster file");
> > + G_fatal_error("error while writing to raster file (disk full?)");
> > unlink(temp_name);
--
Markus Neteler
ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
Project on Predictive Models for the Environment
Via Sommarive, 18 - 38050 Povo (Trento), Italy
tel +39 0461 314 -520 (fax -591) http://mpa.itc.it
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
On Fri, Aug 23, 2002 at 04:14:10PM +0200, Markus Neteler wrote:
On Fri, Aug 23, 2002 at 03:59:18PM +0200, Markus Neteler wrote:
> On Fri, Aug 23, 2002 at 03:49:46PM +0200, Bernhard Reiter wrote:
> > To help diagnosing this it might be helpful to give the filename
> > in the error message where writing was attempted.
> > I would replace the "(disk full?)" comment by
> > ". You might want to check available disk space and write permissions."
> submitted. thanks.
It may be even nice to see *which* partition is full.
This is why I think you should output the filename
in question, it would allow analysis. 
At least here it's difficult, we have a complicated mixture
of NFS linked machines with lot's of partitions. Is there
a portable method to print which partition is full?
Not that I know.
"df" and "mount" help a lot on many unix machines.
Bernhard Reiter wrote:
Certainly there can be more reasons why writing wouldn't work.
Like nfs down or wrong permission?
To help diagnosing this it might be helpful to give the filename
in the error message where writing was attempted.
I would replace the "(disk full?)" comment by
". You might want to check available disk space and write permissions."
I would just print the error message corresponding to the OS error,
using perror() or strerror(). E.g. an error of ENOSPC would result in
something like "No space left on device" (the exact message depends
upon your libc).
--
Glynn Clements <glynn.clements@virgin.net>
Markus Neteler wrote:
> > To help diagnosing this it might be helpful to give the filename
> > in the error message where writing was attempted.
> > I would replace the "(disk full?)" comment by
> > ". You might want to check available disk space and write permissions."
>
> submitted. thanks.
It may be even nice to see *which* partition is full.
At least here it's difficult, we have a complicated mixture
of NFS linked machines with lot's of partitions. Is there
a portable method to print which partition is full?
If you have the pathname available, then you can scan the list of
mounted filesystems (using getmntent() etc), and select the closest
ancestor to the file in question. However, you would need the
canonical pathname (the one for which none of the components are
symlinks).
If you don't have the pathname, just the descriptor, then there isn't
any portable solution. There are some hacks available, but most of
them don't work for NFS mounts (for which there is no "device").
I'd suggest just including whatever information is readily available
(e.g. pathname or map name) in the error message.
--
Glynn Clements <glynn.clements@virgin.net>