Hamish:
> Can anyone else copy vector maps in windows?
Markus:
in manage/lib/do_copy.c, 'mkdir' is used which IMHO needs a special
treatment on Windows. See for example lib/gis/mapset_msc.c
here I leave this bug- I leave Windows developement as a challenge for
others to pursue.
Hamish
Hamish wrote on 12/07/2006 09:28 AM:
Hamish:
Can anyone else copy vector maps in windows?
Markus:
in manage/lib/do_copy.c, 'mkdir' is used which IMHO needs a special
treatment on Windows. See for example lib/gis/mapset_msc.c
here I leave this bug- I leave Windows developement as a challenge for
others to pursue.
There are some candidates for this fix (contains some false positives):
find . -type f -name "*.c" -exec grep -l mkdir {} \;
./general/manage/lib/do_copy.c
./raster/r.li/r.li.daemon/daemon.c
./raster/r.le/r.le.setup/main.c
./raster/r.le/r.le.patch/main.c
./raster/r.le/r.le.pixel/main.c
./lib/init/mke_mapset.c
./lib/init/mke_loc.c
./lib/db/dbmi_driver/d_mkdir.c
./lib/gis/make_mapset.c
./lib/gis/make_loc.c
./lib/gis/mapset_msc.c
./lib/gis/win32_pipes.c
./lib/gis/unix_socks.c
./lib/gis/paths.c
./lib/gis/user_config.c
./lib/raster/io_fifo.c
./lib/g3d/g3dwindowio.c
./gem/reg_entries.c
./gem/actions.c
lib/gis/paths.c
Probably a search/replace of ' mkdir' would do, using G_mkdir() from
./lib/gis/paths.c
? Or we need to modify G_mkdir() to accepts two parameters.
Markus
Markus Neteler wrote:
>> in manage/lib/do_copy.c, 'mkdir' is used which IMHO needs a special
>> treatment on Windows. See for example lib/gis/mapset_msc.c
>>
>
> here I leave this bug- I leave Windows developement as a challenge for
> others to pursue.There are some candidates for this fix (contains some false positives):
find . -type f -name "*.c" -exec grep -l mkdir {} \;
./general/manage/lib/do_copy.c
./raster/r.li/r.li.daemon/daemon.c
./raster/r.le/r.le.setup/main.c
./raster/r.le/r.le.patch/main.c
./raster/r.le/r.le.pixel/main.c
./lib/init/mke_mapset.c
./lib/init/mke_loc.c
./lib/db/dbmi_driver/d_mkdir.c
./lib/gis/make_mapset.c
./lib/gis/make_loc.c
./lib/gis/mapset_msc.c
./lib/gis/win32_pipes.c
./lib/gis/unix_socks.c
./lib/gis/paths.c
./lib/gis/user_config.c
./lib/raster/io_fifo.c
./lib/g3d/g3dwindowio.c
./gem/reg_entries.c
./gem/actions.c
lib/gis/paths.cProbably a search/replace of ' mkdir' would do, using G_mkdir() from
./lib/gis/paths.c
? Or we need to modify G_mkdir() to accepts two parameters.
No, G_mkdir() is fine.
On Unix, the mode argument should always be 0777, so the user has
complete control of the permissions via their umask; anything which
uses a more restrictive mode is second-guessing the user.
The only programs which should be setting permissions explicitly are
those which provide some other mechanism for the user to control the
permissions.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, Dec 07, 2006 at 12:02:09PM +0000, Glynn Clements wrote:
Markus Neteler wrote:
...
> Probably a search/replace of ' mkdir' would do, using G_mkdir() from
> ./lib/gis/paths.c
> ? Or we need to modify G_mkdir() to accepts two parameters.No, G_mkdir() is fine.
On Unix, the mode argument should always be 0777, so the user has
complete control of the permissions via their umask; anything which
uses a more restrictive mode is second-guessing the user.The only programs which should be setting permissions explicitly are
those which provide some other mechanism for the user to control the
permissions.
I have done the changes to G_mkdir() accordingly.
Also added a G_lstat() in lib/gis/paths.c for a similar
problem.
Find attached a diff for review.
The following 3 functions are too complicated for me (!)
to fix:
G_mkdir TODOS:
lib/g3d/g3dwindowio.c
lib/gis/mapset_msc.c
lib/raster/io_fifo.c
Feedback welcome,
Markus
G_mkdir.diff (8.62 KB)
Markus Neteler wrote:
> > Probably a search/replace of ' mkdir' would do, using G_mkdir() from
> > ./lib/gis/paths.c
> > ? Or we need to modify G_mkdir() to accepts two parameters.
>
> No, G_mkdir() is fine.
>
> On Unix, the mode argument should always be 0777, so the user has
> complete control of the permissions via their umask; anything which
> uses a more restrictive mode is second-guessing the user.
>
> The only programs which should be setting permissions explicitly are
> those which provide some other mechanism for the user to control the
> permissions.I have done the changes to G_mkdir() accordingly.
Also added a G_lstat() in lib/gis/paths.c for a similar
problem.Find attached a diff for review.
The following 3 functions are too complicated for me (!)
to fix:
G_mkdir TODOS:
lib/g3d/g3dwindowio.c
The only code here which uses mkdir() is commented out.
lib/gis/mapset_msc.c
I'm currently testing the attached patch.
lib/raster/io_fifo.c
Can't we just kill this? I don't even know if it still works, given
that almost no-one actually uses --enable-fifo.
In any case, I doubt that file will work on Windows.
--
Glynn Clements <glynn@gclements.plus.com>
mkdir-stat.diff (2.67 KB)
Glynn Clements wrote:
> The following 3 functions are too complicated for me (!)
> to fix:
> lib/gis/mapset_msc.c
I'm currently testing the attached patch.
I'm surprised I managed to make so many mistakes for such a relatively
small change. I've attached an updated patch; apart from eliminating
the compilation errors, it eliminates the warnings arising from the
addition of G_lstat().
--
Glynn Clements <glynn@gclements.plus.com>
mkdir-stat.diff (3.06 KB)
Glynn Clements wrote:
I've attached an updated patch; apart from eliminating
the compilation errors, it eliminates the warnings arising from the
addition of G_lstat().
However, photo.elev fails to compile due to a conflicting use of
"stat" in elev.h.
In retrospect, this is probably sufficient (and less problematic):
--- include/gisdefs.h 13 Dec 2006 16:48:41 -0000 1.74
+++ include/gisdefs.h 13 Dec 2006 22:57:17 -0000
@@ -870,6 +870,7 @@
int G_is_dirsep(char);
char *G_convert_dirseps_to_host(char *);
char *G_convert_dirseps_from_host(char *);
+struct stat;
int G_lstat(const char *, struct stat *);
/* percent.c */
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote on 12/13/2006 11:58 PM:
Glynn Clements wrote:
I've attached an updated patch; apart from eliminating
the compilation errors, it eliminates the warnings arising from the
addition of G_lstat().
However, photo.elev fails to compile due to a conflicting use of
"stat" in elev.h.In retrospect, this is probably sufficient (and less problematic):
--- include/gisdefs.h 13 Dec 2006 16:48:41 -0000 1.74
+++ include/gisdefs.h 13 Dec 2006 22:57:17 -0000
@@ -870,6 +870,7 @@
int G_is_dirsep(char);
char *G_convert_dirseps_to_host(char *);
char *G_convert_dirseps_from_host(char *);
+struct stat;
int G_lstat(const char *, struct stat *);/* percent.c */
Thanks Glynn. So should I submit the other changes then?
Markus
I have now submitted the G_mkdir() and G_lstat() changes.
Hopefully a help for portability.
Markus
On Wed, Dec 13, 2006 at 07:49:12PM +0000, Glynn Clements wrote:
Markus Neteler wrote:
...
> lib/raster/io_fifo.c
Can't we just kill this? I don't even know if it still works, given
that almost no-one actually uses --enable-fifo.In any case, I doubt that file will work on Windows.
If we don't need it, let's remove it. Unused code is only
confusing.
Markus
> > lib/raster/io_fifo.c
>
> Can't we just kill this? I don't even know if it still works, given
> that almost no-one actually uses --enable-fifo.
>
> In any case, I doubt that file will work on Windows.If we don't need it, let's remove it. Unused code is only
confusing.
just for curiosity, what's the (dis)advantage of using FIFO vs sockets?
Hamish
Hamish wrote:
> > > lib/raster/io_fifo.c
> >
> > Can't we just kill this? I don't even know if it still works, given
> > that almost no-one actually uses --enable-fifo.
> >
> > In any case, I doubt that file will work on Windows.
>
> If we don't need it, let's remove it. Unused code is only
> confusing.just for curiosity, what's the (dis)advantage of using FIFO vs sockets?
Ugly code, not particularly robust, needs a global mode 1777
(world-writable, sticky-bit) directory for lock files (and thus the
need to deal with stale lock files), need to pre-create the FIFOs.
Also the need to store their paths in etc/monitorcap, which means
modifying it if you move the GRASS installation:
http://grass.itc.it/pipermail/grass-dev/2003-February/007083.html
[Currently, we store relative paths, which don't actually work.]
The "obvious" mechanism for client-server communication is a socket.
The FIFO code existed for systems which don't have sockets. Nowadays,
such systems are about as common as 8-inch floppies or punched cards.
I only know of one person (Bev Wallace) who was actually using the
FIFO option, and that appears to be no longer relevant:
http://grass.itc.it/pipermail/grass-dev/2003-February/007095.html
--
Glynn Clements <glynn@gclements.plus.com>