When trying to “cp”, “mv”, or “rm” a large number of files (I did a test
with 100,000 files) from a single directory, I get the following message
: “Interrupted function call”. I am hoping that there is a fix for
this, as our systems are used for data acquisition, and the number of
files can get to be quite large.
When I tried to delete files using the Photon File Manager, the results
were a little better, but there is still a problem were the directoty is
not completely read.
The following is the output from “sin ver”:
PROGRAM NAME VERSION DATE
/boot/sys/Proc32 Proc 4.25J Sep 09 1999
/boot/sys/Proc32 Slib16 4.23G Oct 04 1996
/boot/sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24T Feb 26 1999
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.24Q Jun 28 1999
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.par Dev32.par 4.25A Jan 08 2001
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Net Net 4.25C Aug 30 1999
//1/bin/Net.rtl Net.rtl 4.25C Jan 09 2001
//1/bin/Fsys.eide eide 4.25A Feb 09 2000
//1/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//1/bin/Dosfsys Dosfsys 4.23E Jan 21 1997
//1//usr/ucb/Socklet Socklet 4.25H Jul 30 1999
//1/bin/SMBfsys SMBfsys 1.30I Dec 07 1999
//1//photon/bin/Photon Photon 1.14B Sep 03 1999
//1/*/bin/phfontpfr Photon Font 1.14H Jun 05 2000
Thanks in advance for any help,
Ian Todd,
NDT Technologies Inc.
Some more information:
“rm *” from the directory in question will result in the “Interrupted
function call” message
“rm -R Files” will work from the parent directory.
I wrote a small program to delete the files one by one (using unlink)
and it works fine (I tested on 40,000 files).
Is this a known issue?
If there is any more information that I can give - please let me know.
Ian Todd
NDT Technologies Inc.
“NDT Technologies Inc.” <info@ndt.ca> wrote in message
news:3D877F96.9C6C37A3@ndt.ca…
When trying to “cp”, “mv”, or “rm” a large number of files (I did a test
with 100,000 files) from a single directory, I get the following message
: “Interrupted function call”. I am hoping that there is a fix for
this, as our systems are used for data acquisition, and the number of
files can get to be quite large.
When I tried to delete files using the Photon File Manager, the results
were a little better, but there is still a problem were the directoty is
not completely read.
The following is the output from “sin ver”:
PROGRAM NAME VERSION DATE
/boot/sys/Proc32 Proc 4.25J Sep 09 1999
/boot/sys/Proc32 Slib16 4.23G Oct 04 1996
/boot/sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24T Feb 26 1999
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.24Q Jun 28 1999
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.par Dev32.par 4.25A Jan 08 2001
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Net Net 4.25C Aug 30 1999
//1/bin/Net.rtl Net.rtl 4.25C Jan 09 2001
//1/bin/Fsys.eide eide 4.25A Feb 09 2000
//1/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//1/bin/Dosfsys Dosfsys 4.23E Jan 21 1997
//1//usr/ucb/Socklet Socklet 4.25H Jul 30 1999
//1/bin/SMBfsys SMBfsys 1.30I Dec 07 1999
//1//photon/bin/Photon Photon 1.14B Sep 03 1999
//1/*/bin/phfontpfr Photon Font 1.14H Jun 05 2000
Thanks in advance for any help,
Ian Todd,
NDT Technologies Inc.
“Ian Todd” <iantodd@sympatico.ca> wrote in message
news:amb56r$dqs$1@inn.qnx.com…
Some more information:
“rm *” from the directory in question will result in the “Interrupted
function call” message
I beleive the * is expanded by the shell, if you have lots of file maybe it
the shell is barfing on sheer size of the resulting arguments
“rm -R Files” will work from the parent directory.
I wrote a small program to delete the files one by one (using unlink)
and it works fine (I tested on 40,000 files).
Is this a known issue?
If there is any more information that I can give - please let me know.
Ian Todd
NDT Technologies Inc.
“NDT Technologies Inc.” <> info@ndt.ca> > wrote in message
news:> 3D877F96.9C6C37A3@ndt.ca> …
When trying to “cp”, “mv”, or “rm” a large number of files (I did a test
with 100,000 files) from a single directory, I get the following message
: “Interrupted function call”. I am hoping that there is a fix for
this, as our systems are used for data acquisition, and the number of
files can get to be quite large.
When I tried to delete files using the Photon File Manager, the results
were a little better, but there is still a problem were the directoty is
not completely read.
The following is the output from “sin ver”:
PROGRAM NAME VERSION DATE
/boot/sys/Proc32 Proc 4.25J Sep 09 1999
/boot/sys/Proc32 Slib16 4.23G Oct 04 1996
/boot/sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24T Feb 26 1999
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.24Q Jun 28 1999
//1/usr/bin/lpsrvr lpsrvr 4.24A Jun 26 1997
//1/bin/Dev32 Dev32 4.23G Oct 04 1996
//1/bin/Pipe Pipe 4.23A Feb 26 1996
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//1/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//1/bin/Dev32.par Dev32.par 4.25A Jan 08 2001
//1/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//1/bin/Net Net 4.25C Aug 30 1999
//1/bin/Net.rtl Net.rtl 4.25C Jan 09 2001
//1/bin/Fsys.eide eide 4.25A Feb 09 2000
//1/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//1/bin/Dosfsys Dosfsys 4.23E Jan 21 1997
//1//usr/ucb/Socklet Socklet 4.25H Jul 30 1999
//1/bin/SMBfsys SMBfsys 1.30I Dec 07 1999
//1//photon/bin/Photon Photon 1.14B Sep 03 1999
//1/*/bin/phfontpfr Photon Font 1.14H Jun 05 2000
Thanks in advance for any help,
Ian Todd,
NDT Technologies Inc.
\
Mario Charest postmaster@127.0.0.1 wrote:
: “Ian Todd” <iantodd@sympatico.ca> wrote in message
: news:amb56r$dqs$1@inn.qnx.com…
:> Some more information:
:>
:> “rm *” from the directory in question will result in the “Interrupted
:> function call” message
: I beleive the * is expanded by the shell, if you have lots of file maybe it
: the shell is barfing on sheer size of the resulting arguments
You can always use find and pass the results to xargs. For example:
find . -name “*.c” | xargs grep -li something | less
If you need to quote an argument in the xargs command, you might have to
quote it twice:
find . -name “*.c” | xargs grep -li “‘some string’” | less
I use this kind of construction frequently.
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
It seems that the maximum number of files that I can use with a wildcard “*”, is
just under 5000 on my system.
Doing all copying / moving / deleting from the parent directory seems to work.
So I will do it this way for now.
Using the “xargs” would work nicely, but be more difficult for the operators of
our equipment.
Thanks.
Ian
NDT Technologies Inc.
Steve Reid wrote:
Mario Charest postmaster@127.0.0.1 wrote:
: “Ian Todd” <> iantodd@sympatico.ca> > wrote in message
: news:amb56r$dqs$> 1@inn.qnx.com> …
:> Some more information:
:
:> “rm *” from the directory in question will result in the “Interrupted
:> function call” message
: I beleive the * is expanded by the shell, if you have lots of file maybe it
: the shell is barfing on sheer size of the resulting arguments
You can always use find and pass the results to xargs. For example:
find . -name “*.c” | xargs grep -li something | less
If you need to quote an argument in the xargs command, you might have to
quote it twice:
find . -name “*.c” | xargs grep -li “‘some string’” | less
I use this kind of construction frequently.
Steve Reid > stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
“NDT Technologies Inc.” <info@ndt.ca> wrote in message
news:3D8A2D2B.6904B35B@ndt.ca…
It seems that the maximum number of files that I can use with a wildcard
“*”, is
just under 5000 on my system.
The limit is not the number of files, but the length of the command line.
As mentioned, the wildcard is expanded by the shell and the resulting
command line is passed to the command (‘rm’ in this case).
If you tried this with longer filenames you’d find that it would handle
fewer files. Shorter filenames and you get more files.
When you used the construct “rm -r dir” you used a very small command line.
Doing all copying / moving / deleting from the parent directory seems to
work.
So I will do it this way for now.
Using the “xargs” would work nicely, but be more difficult for the
operators of
our equipment.
So create a shell script cover for this, perhaps call “rmall”. Then the
operators only have to remember a single, simple command.
P.S. Knowing the QNX4 filesystem quite well (mild understatement) I would
design logging applications such as you have so that they log files into a
tree of directories, organized in some logical fashion such as by time.
This would limit the number of files per directory and let the filesystem
operate something like a binary tree database, speeding up access to the
files and making everything much more efficient. When I say “everything” I
mean opening files, removing (unlinking) files, etc.
Bill Flowers
Insight Control Systems
Safety Harbor, FL
“William A. Flowers” <wflowers_NOSPAM@insightcontrol.com> wrote in message
news:an1lkb$qrf$1@inn.qnx.com…
P.S. Knowing the QNX4 filesystem quite well (mild understatement) I would
design logging applications such as you have so that they log files into a
tree of directories, organized in some logical fashion such as by time.
This would limit the number of files per directory and let the filesystem
operate something like a binary tree database, speeding up access to the
files and making everything much more efficient. When I say “everything”
I
mean opening files, removing (unlinking) files, etc.
Another thing that I do is to put log type files into a partition just for
log files. Log files, any files that grow a little at a time, will become
very fragmented. They can also cause other files or at least partitions to
become somewhat fragmented. By keeping log files in their own partition
this minimizes the impact on the rest of the system.