Re: g_spawn and files left locked on windows.
On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote:
My application invokes the lilypond program using the g_spawn...
functions. This works fine on linux, but on windows the files created by
lilypond are left locked when lilypond has exited.
That sounds very odd and in fact impossible. Are you confusing file
protection with locking?
Thank you for the quick and helpful reply. Having contstructed the
minimal example, everything worked fine.
For those listening in who need to create a glib standalone minimal
example. I append the code I devised.
Richard
/ first program, invoked by the one below */
#include stdio.h
/*
program doit
gcc test.c -o doit.exe
*/
int main(void) {
printf(Opening the test file now\n);
FILE *fp = fopen(thetestfile,w);
if(fp==NULL) {
printf(doit could not open the test file);
return -1;
}
printf(Writing to the test file now\n);
fprintf(fp, hello);
fclose(fp);
return 0;
}
/** second program, invoking the first */
/*
program test
gcc test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
/usr/lib/libglib-2.0.so
*/
#include stdio.h
#include glib.h
static GPid pid = -1;
void finished(void) {
g_spawn_close_pid (pid);
FILE *fp = fopen(thetestfile,rw);
if(fp==NULL) {
g_print(could not open\n);
exit(-1);
}
g_print(The file opens ok\n);
exit(0);
}
int main(void) {
g_print(Starting the test\n);
gchar *arguments[] = {
doit.exe,
NULL
};
g_spawn_async_with_pipes (NULL, /* dir */
arguments, NULL,/* env */
G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /*
child setup func */
NULL, /* user data */
pid,
NULL,
NULL, /* stdout */
NULL, /* stderr */
NULL);
g_child_watch_add (pid, (GChildWatchFunc)finished, NULL);
g_print(looping for ever, Ctrl-C to kill\n);
GMainLoop* gm = g_main_loop_new(NULL, 0);
g_main_loop_run(gm);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn and files left locked on windows.
As far i know in win32, if a process is opening a new file, then normally
another process couldn't write or remove it. It's maybe a synchronization
method offered by win32 by automatically locking a file descriptor. Linux
doesn't automatically provide such a file locking mechanism to a file opened by
a process.
So if the file left locked, there are must be a process which still open the
file or a file is still left opened. Win32 maybe doesn't automatically release
such as opened file's resources.
In your project or demonstration code: I see you don't fclose() your file
before exit (actually i don't know if this have the 'locking effect'), and you
may interest using a GIOChannel for file operations.
--- ajhwb
--- richard.sh...@virgin.net wrote:
From: Richard Shann richard.sh...@virgin.net
To: gtk-app-devel-list@gnome.org
Subject: Re: g_spawn and files left locked on windows.
Date: Tue, 28 Apr 2009 08:39:12 +0100
On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote:
My application invokes the lilypond program using the g_spawn...
functions. This works fine on linux, but on windows the files created by
lilypond are left locked when lilypond has exited.
That sounds very odd and in fact impossible. Are you confusing file
protection with locking?
Thank you for the quick and helpful reply. Having contstructed the
minimal example, everything worked fine.
For those listening in who need to create a glib standalone minimal
example. I append the code I devised.
Richard
/ first program, invoked by the one below */
#include stdio.h
/*
program doit
gcc test.c -o doit.exe
*/
int main(void) {
printf(Opening the test file now\n);
FILE *fp = fopen(thetestfile,w);
if(fp==NULL) {
printf(doit could not open the test file);
return -1;
}
printf(Writing to the test file now\n);
fprintf(fp, hello);
fclose(fp);
return 0;
}
/** second program, invoking the first */
/*
program test
gcc test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
/usr/lib/libglib-2.0.so
*/
#include stdio.h
#include glib.h
static GPid pid = -1;
void finished(void) {
g_spawn_close_pid (pid);
FILE *fp = fopen(thetestfile,rw);
if(fp==NULL) {
g_print(could not open\n);
exit(-1);
}
g_print(The file opens ok\n);
exit(0);
}
int main(void) {
g_print(Starting the test\n);
gchar *arguments[] = {
doit.exe,
NULL
};
g_spawn_async_with_pipes (NULL, /* dir */
arguments, NULL,/* env */
G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /*
child setup func */
NULL, /* user data */
pid,
NULL,
NULL, /* stdout */
NULL, /* stderr */
NULL);
g_child_watch_add (pid, (GChildWatchFunc)finished, NULL);
g_print(looping for ever, Ctrl-C to kill\n);
GMainLoop* gm = g_main_loop_new(NULL, 0);
g_main_loop_run(gm);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
_
Listen to KNAC, Hit the Home page and Tune In Live! --- http://www.knac.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn and files left locked on windows.
Thank you for your observations.
On Tue, 2009-04-28 at 07:45 -0700, Ardhan Madras wrote:
As far i know in win32, if a process is opening a new file, then normally
another process couldn't write or remove it.
yes that's right.
It's maybe a synchronization method offered by win32 by automatically
locking a file descriptor. Linux doesn't automatically provide such a file
locking mechanism to a file opened by a process.
So if the file left locked, there are must be a process which still open the
file or a file is still left opened. Win32 maybe doesn't automatically
release such as opened file's resources.
The process had finished, and that was why I was puzzled.
In your project or demonstration code: I see you don't fclose() your file
before exit
I *do* fclose() the file in the program that creates it (i.e. in the
program doit). It is also guaranteed to be closed by the main of that
program returning, that is as part of the exit. The other program is
just finding out if the file is locked by trying to open it, so it
doesn't matter what it does with it. The test does, in fact work
pefectly on both platforms, so my problem lay elsewhere.
Richard
(actually i don't know if this have the 'locking effect'), and you may
interest using a GIOChannel for file operations.
--- ajhwb
--- richard.sh...@virgin.net wrote:
From: Richard Shann richard.sh...@virgin.net
To: gtk-app-devel-list@gnome.org
Subject: Re: g_spawn and files left locked on windows.
Date: Tue, 28 Apr 2009 08:39:12 +0100
On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote:
My application invokes the lilypond program using the g_spawn...
functions. This works fine on linux, but on windows the files created by
lilypond are left locked when lilypond has exited.
That sounds very odd and in fact impossible. Are you confusing file
protection with locking?
Thank you for the quick and helpful reply. Having contstructed the
minimal example, everything worked fine.
For those listening in who need to create a glib standalone minimal
example. I append the code I devised.
Richard
/ first program, invoked by the one below */
#include stdio.h
/*
program doit
gcc test.c -o doit.exe
*/
int main(void) {
printf(Opening the test file now\n);
FILE *fp = fopen(thetestfile,w);
if(fp==NULL) {
printf(doit could not open the test file);
return -1;
}
printf(Writing to the test file now\n);
fprintf(fp, hello);
fclose(fp);
return 0;
}
/** second program, invoking the first */
/*
program test
gcc test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
/usr/lib/libglib-2.0.so
*/
#include stdio.h
#include glib.h
static GPid pid = -1;
void finished(void) {
g_spawn_close_pid (pid);
FILE *fp = fopen(thetestfile,rw);
if(fp==NULL) {
g_print(could not open\n);
exit(-1);
}
g_print(The file opens ok\n);
exit(0);
}
int main(void) {
g_print(Starting the test\n);
gchar *arguments[] = {
doit.exe,
NULL
};
g_spawn_async_with_pipes (NULL, /* dir */
arguments, NULL,/* env */
G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /*
child setup func */
NULL, /* user data */
pid,
NULL,
NULL, /* stdout */
NULL, /* stderr */
NULL);
g_child_watch_add (pid, (GChildWatchFunc)finished, NULL);
g_print(looping for ever, Ctrl-C to kill\n);
GMainLoop* gm = g_main_loop_new(NULL, 0);
g_main_loop_run(gm);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
_
Listen to KNAC, Hit the Home page and Tune In Live! --- http://www.knac.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn and files left locked on windows.
The process had finished, and that was why I was puzzled. But had the process perhaps started some child process that had (unintentionally) inherited the file handle, and that child process was still running? Please install Process Explorer from sysinternals.com and use its FindFind Handle or DLL functionality to find out open handles to a file. Process Explorer is an extremely useful tool in many other ways, too. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_spawn and files left locked on windows.
My application invokes the lilypond program using the g_spawn... functions. This works fine on linux, but on windows the files created by lilypond are left locked when lilypond has exited. That sounds very odd and in fact impossible. Are you confusing file protection with locking? Please file a bug report at bugzilla.gnome.org and *attach* a *minimal* (single C or Python source file) but *complete* (can be compiled and run as such) sample program that reproduces the problem, *without* using lilypond. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_spawn and files left locked on windows.
My application invokes the lilypond program using the g_spawn... functions. This works fine on linux, but on windows the files created by lilypond are left locked when lilypond has exited. I can't re-use them on the next invocation, for example. Should I be exploring this as a possible bug in lilypond, or could there be something about the way I invoke it? Richard Shann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
