Xuedong Chen <Xuedong.Chen@igt.com> wrote:
Thanks.
It revealed that it works for my QNX box, but not for my Win2000 box.
I am working under cross developmenet environment. I use fs-cifs to mount my
working directory in my Win2000 box into QNX filesystem, I compile/link my
test code in my Win2000 box (Metrowerks), then use telnet run my test code,
here is the result:
-
When my test code and myfile.dat reside in Win2000 box, the ftruncate ()
doesn’t work properly. (it tells OK, but no action.)
-
When I copied the test code and myfile.dat to QNX box, and try there, it
did work, I guess just like what you tried.
Actually, I can copy files from QNX box to my working directory in Wind2000
box, how does 1) not work? Can you reproduce it in your case? or just my
specific problem?
Under QNX, it is really important to understand/tell us “which server”
you are dealing with, while you report the problem.
A “file” could exist on local harddisk, which means while you “ftruncate”
it, you are talking to the “server” who taking care of harddisk, in
this case, “devb-eide” program. That is usually what we thought when
you say "I can’t xxx a file "
However, a “file” could also exist on a flash-filesystem, or under
NFS mount point, or even in memory (image file system), each have
a different server taking resposibilty.
In your case, a “file” under “fs-cifs”'d directory can not be
ftruncate, which tells us the “server” who’s taking care of that
direcotry (yes, the program “fs-cifs”) is not working properly.
I am sure whoever response to “fs-cifs” here will take a look
of the problem soon.
To answer the question “why copy works, ftruncate() don’t?”
Well it’s simply because “cp” are sending different message
to the server.
Hope this could be helpful.
-xtang
Xuedong
“Jason Clarke” <> jclarke@qnx.com> > wrote in message
news:9jkbfi$ft7$> 1@nntp.qnx.com> …
/tmp-
/tmp->ls -l myfile.dat
-rw-rw-r-- 1 jclarke 100 1024 Jul 25 01:31 myfile.dat
/tmp->qcc z.cc
/tmp->./a.out myfile.dat
file des = 3
no problem in using ftruncate ().
/tmp->ls -l myfile.dat
-rw-rw-r-- 1 jclarke 100 16384 Jul 25 01:31 myfile.dat
/tmp-
It seems to work for me just fine.
Is this on a desktop machine with a full install of 6.1?
or is it happening on a custom board?
Jason
Xuedong Chen <> Xuedong.Chen@igt.com> > wrote:
Here is my simple test code. I have a fle named “myfile.dat” under the
same
directory as my process.
int main (int argc, char * argv [])
{
// This code works under 6.0, but not 6.1
int fd = open (“myfile.dat”,
O_WRONLY | O_CREAT | O_APPEND,
S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP
| S_IROTH | S_IWOTH );
// Tried this under 6.1, it tells OK, but nothing happened to
“myfile.dat”
//int fd = open (“myfile.dat”,
// O_RDWR | O_APPEND, 0777);
if (fd > 2)
{
cout << "file des = " << fd << endl;
if (ftruncate (fd, 0x4000) == -1)
cout << "ftruncate () has some problems, errno = " << errno
endl;
else
cout << “no problem in using ftruncate ().” << endl;
}
else
cout << “can not open myfile.dat” << endl;
…
}
BTW, I just tried the flags you used, it tells OK, but nothing happened
to
“myfile.dat”
Xuedong
“Jason Clarke” <> jclarke@qnx.com> > wrote in message
news:9jhthk$t8v$> 1@nntp.qnx.com> …
Here is how I tested it, and it seems to work.
#include <unistd.h
#include <sys/types.h
#include <sys/stat.h
#include <fcntl.h
int main(int argc, char **argv)
{
int fd, size;
size = atoi(argv[2]);
fd = open(argv[1], O_WRONLY | O_CREAT, 0666);
if(fd == -1) {
perror("open ");
exit(1);
}
if(ftruncate(fd, size) == -1) {
perror("ftruncate ");
exit(1);
}
close(fd);
return(0);
}
Maybe you could share what the error you are getting is?
Jason
Xuedong Chen <> Xuedong.Chen@igt.com> > wrote:
Hi, All;
I am having a problem in using ftruncate () in my application under
QNX
6.1.
I did a simple test: it seems ftrncate () works for 6.0, but not for
6.1.
I opened a file of 1K size as write-only then use ftruncate () to
expand
it
to 16K, it worked under 6.0, but tells error under 6.1, then I
changed
the
flag to write-read, it tells OK not actully did nothing to the file,
my
file
still stay the same size.
I will appreciate that you can verify this problem and get it fixed
if
it is
a bug for 6.1
Thanks.
Xuedong
\