Mail Archives: cygwin/2006/05/06/16:49:44
Andy AT Jet-Net wrote:
[snip]
> Is there any way of checking which particular Windows.dll it could be
> needing?
cygcheck <program>
will list the dynamic libraries used.
> Could there be any serial port setting that may be affecting it?
I don't see how.
> Incidentally I'm run a one minute cron job (for the working process) - wo=
uld
> that affect anything?
Could be, if the process runs more than once concurrently and tries to acce=
ss
the same file. It certainly will try to access the same port.
[snip]
>>> Is there a limit to the number of files on XP - like the old config.sys
>>> option files=3D99?
>> I don't know.
> Would archiving files to a separate directory help?
I don't know what functionality you are looking for, do you expect a limit =
on
the number of files on a directory? Windows does have a limit on the size =
of a
path, and there is a limit on the number of files but it is pretty big (I d=
on't
remember it at the moment.)
[snip]
> Incidentally I tried something else today. I created a shell script junk.=
sh
> that did the following:
>=20
> echo "starting problem program"
> ./problem_program
> echo "ending problem program"
>=20
> I ran this with=20
> ./junk.sh > junk.txt
>=20
> Surprise, surprise in junk.txt I got=20
> starting problem program
> ending problem program
>=20
> with again none of problem_program's output!
This is only on one machine, right? just as if you are closing stdout.
There are many possibilities but none will stand if the program works one w=
ay on
a computer and another way on a different computer. So the most probable c=
ause
is some difference between computers.
> * Is the chkdsk error significant, or is it just a "red herring" do you t=
hink?
I don't see how it could be a factor, but I may be missing something. Bett=
er
try to see what's the cause (a damaged sector that cannot be remapped?).
> * Have you ever heard of anything similar on Linux/Unix?
Anything is possible. For instance, an uninitialized pointer could cause
writing in the file descriptor table same effect as closing/changing those =
file
descriptors, if the program is not too complex I would use gdb to see the
execution at least once, if it is complex then better isolate the problem f=
irst.
> * Does windows have a lock on a file or something?
Yes. You probably have seen it, when Windows doesn't allow you to delete a=
file
because it is "in use" (try deleting all the .tmp files in your temp direct=
ory).
> * I'm sure I haven't, but if something in the program redirected 'stdout',
> would this have any affect like I'm experiencing - i.e. overriding the
> command line's redirection?
As I said, anything is possible. The important clue is that it runs always=
on
one computer, it never runs on another (I should really say "seems to").
--=20
Ren=E9 Berber
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -