Linux-Development-Apps Digest #474, Volume #7 Fri, 15 Jun 01 19:13:15 EDT
Contents:
Re: Matt Blaze's CFS on Linux - readdir problem. (Kevin Buhr)
Re: Parrot-0.2.6 released (phil hunt)
Redefinition Error (Cameron Cooper)
Re: where can i get Koffice or star office..
Re: sockets: anyone recognizes this symptom on a server?
Re: Redefinition Error (Erik Max Francis)
Re: sockets: anyone recognizes this symptom on a server? (Carlos Moreno)
Re: sharing Pthread mutexes among processes (Adam Fineman)
thread timing info, suspending threads (Michael Harvey)
Re: sharing Pthread mutexes among processes (Adam Fineman)
Ending thread blocked in I/O ("Timur Aydin")
Re: kylix (quux111)
creating a large file on ext2 fs (Jeremy D. Mullin)
Re: creating a large file on ext2 fs (nordi)
Re: creating a large file on ext2 fs (Chris Cox)
Re: getopt + optional parameter (Jerry Peters)
problem with select() function ?! (Oliver Kowalke)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Kevin Buhr)
Crossposted-To:
comp.os.linux.security,comp.os.linux.misc,comp.os.linux.development.system
Subject: Re: Matt Blaze's CFS on Linux - readdir problem.
Date: 15 Jun 2001 12:20:21 -0500
[[ Followup-to: comp.os.linux.security,comp.os.linux.development.apps ]]
"Binesh Bannerjee" <[EMAIL PROTECTED]> writes:
>
> Have you done much with cattach -l ? Do you know how that works?
"-l" suppresses the creation of what Matt calls perturbation vectors.
A perturbation vector is randomly generated for each newly created
file, and it's XORed against each plaintext block before encryption.
The perturbation vector is then stored in a symlink:
.pvect_<<name of encrypted version of file>>
whose value is the hex representation of the vector. If a file "xxx"
has no associated ".pvect_xxx", the perturbation vector is taken to be
all zero.
The nature of the ECB+OFB encryption scheme used in CFS means that two
files in the same CFS filesystem with the same perturbation vector
value (which will always be zero if you use "-l") will encrypt
plaintext blocks having the same value and located at the same offset
within a file to the same ciphertext.
For example, try:
cattach -l /some/cfs/filesystem x
cd /crypt/x
echo 12345678abcdefghx2345678 >1
echo x2345678abcdefgh12345678 >2
Note that the first and third 64-bit blocks differ between the two
files, but the second 64-bit block of these two files is the same. If
you compare the encrypted versions of these files, you'll discover
that the second 64-bit blocks of the two encrypted files are the same.
The rest of the blocks will all be different.
An attacker could use this to discover which encrypted files had
common headers or, perhaps, to decrypt certain common blocks at some
positions. If the attacker can trick you into storing certain files
(like a large file of all NULLs or files of the repeated string
"Istanbul" at various offsets), he or she can locate chosen
8-character strings in your files.
Dropping "-l" and using pvects prevents this attack.
If you want more information about this, your best bet is to post a
question to "sci.crypt".
> Basically, with cattach -l after I add enough directory entries,
> the _entire_ directory becomes invisible... (There still there, just
> ls or find, whatever won't find them, but you can cd to the directories,
> vi files etc.)
It's probably a different problem, since the bug I described should
always return at least one page of files for a directory read.
I'm not familiar enough with the CFS code to answer your other
question, though.
Kevin <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: gnu.misc.discuss,comp.lang.python
Subject: Re: Parrot-0.2.6 released
Date: Fri, 15 Jun 2001 13:21:55 +0100
On 15 Jun 2001 01:57:39 -0700, Ryan <[EMAIL PROTECTED]> wrote:
>I like the syntax for this much better than the standard TK style for
>python,
That's partly why I worte it -- writing Tkinter code is more time-consuming
than necessary.
It's inspired by the book "Motif Tools" which includes a similar system
fro the Motif GUI.
> pretty amazing for a pre alpha. Looks like it should shorten
>the time for makeing a GUI by a factor of at least 10 for those of us
>that still have to pull out a book everytime we want to make one.
That's the idea. Later this year, I'm likely to be writing some Python
GUI code myself, so I'll be updating Parrot to work with it.
Parrot *does* need work doing to it be be fully useable, but I think
the basic idea is sound.
--
## Philip Hunt ##
## [EMAIL PROTECTED] ##
------------------------------
From: [EMAIL PROTECTED] (Cameron Cooper)
Subject: Redefinition Error
Date: 15 Jun 2001 10:40:32 -0700
Hi,
I'm working on a program and I'm getting this redefinition error,
and I can't figure out why. I have a header file which is included in
almost every .cpp iny my app. The header looks like this:
// CODE ---------------------
#ifndef _XB_H
#define _XB_H
#include "apstring.h"
#include "fstream.h"
struct WORD {
apstring info; // The word
apstring filename; // The file that the word came from
int fileline; // The line that the word came from
WORD * next;
};
ofstream outfile;
apstring current_form_name;
#endif
// CODE ---------------------
That's it...and I get this error from every single file with every
variable in this header:
parse-vb-checkbox.o: In function `WORD::WORD(void)':
/home/cameron/xb/xb/parse-vb-checkbox.cpp(.bss+0x0): multiple
definition of `outfile'
templates.o:/home/cameron/xb/xb/templates.cpp:23: first defined here
parse-vb-checkbox.o: In function `WORD::WORD(void)':
Anyone have any ideas?
Thanks!
Cameron Cooper
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: where can i get Koffice or star office..
Date: Fri, 15 Jun 2001 17:57:44 -0000
In article <[EMAIL PROTECTED]>,
v.nagasrinivas <[EMAIL PROTECTED]> wrote:
> I am using suse 6.3 linux, where can
>i get Koffice or StarOffice for it...
This is a newsgroup. You'll get a fast answer by using
a search engine.
--
http://www.spinics.net/linux/
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: sockets: anyone recognizes this symptom on a server?
Date: Fri, 15 Jun 2001 18:01:54 -0000
In article <[EMAIL PROTECTED]>,
Carlos Moreno <[EMAIL PROTECTED]> wrote:
>Ok, once in a while, when there are many users connected
>(say, 20 or 30 users), communications seem to freeze.
That sounds like some call is blocking that shouldn't. Try using
strace or gdb to find out where.
--
http://www.spinics.net/linux/
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: Redefinition Error
Date: Fri, 15 Jun 2001 11:20:07 -0700
Cameron Cooper wrote:
> That's it...and I get this error from every single file with every
> variable in this header:
>
> parse-vb-checkbox.o: In function `WORD::WORD(void)':
> /home/cameron/xb/xb/parse-vb-checkbox.cpp(.bss+0x0): multiple
> definition of `outfile'
> templates.o:/home/cameron/xb/xb/templates.cpp:23: first defined here
> parse-vb-checkbox.o: In function `WORD::WORD(void)':
>
> Anyone have any ideas?
Because you're (not surprisingly) defining it multiple times.
What you meant (for both outfile and current_form_name) was to declare
it extern in the header and then define it exactly once in only one
module (source file) somewhere.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ God will forgive me; that's his business.
\__/ Heinrich Heine
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
------------------------------
From: Carlos Moreno <[EMAIL PROTECTED]>
Subject: Re: sockets: anyone recognizes this symptom on a server?
Date: Fri, 15 Jun 2001 14:56:56 -0400
[EMAIL PROTECTED] wrote:
> >Ok, once in a while, when there are many users connected
> >(say, 20 or 30 users), communications seem to freeze.
>
> That sounds like some call is blocking that shouldn't. Try using
> strace or gdb to find out where.
Yep, it would seem so. I don't remember any socket activity
other than the clients connected (all of them processed trhough
the main listening loop, using a select with timeout of 10
seconds -- but that would be if there are 10 seconds of silence
in all the sockets). But I guess I'll have to double check...
What is that strace? Is there a way that I could "debug" the
program without being intrusive? (e.g., if I use gdb and, say,
I put a breakpoint, then I'll screw over the normal operation
of the program). And since the problem seems to happen when
there are many users connected, then it looks hard for me to
setup a "debugging environment" with just a few users... :-(
How do people debug these types of systems? :-(
Thanks for your message!
Cheers,
Carlos
--
------------------------------
From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: sharing Pthread mutexes among processes
Date: Fri, 15 Jun 2001 15:22:57 +0000
Marko Asplund wrote:
>
> Adam Fineman wrote:
> >
> > What was unsatisfactory about your semaphore solution?
>
> well, basically there wasn't anything wrong with it. i just
> wanted to implement another, more lightweight mechanism so,
> that i could benchmark the options against each other.
>
If you're using fork() + exec(), then your mechanism is not
"lightweight" (i.e. not threaded). Is there a reason why you cannot
implement a solution that actually uses pthreads?
> i'm using the following code pattern with the Pthread based
> syncronization mechanism:
>
> parent:
> shmid = shmget(IPC_PRIVATE, shmsize, SHM_MODE));
> mtxptr = shmat(shmid, 0, 0);
> pthread_mutexattr_init(&mutex_attr);
> pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);
> pthread_mutex_init(mtxptr, &mutex_attr);
>
> children:
> mtxptr = shmat(shmid, 0, 0);
> pthread_mutex_lock(mtxptr);
>
> here process 1 uses fork() + exec() for starting the children.
> should the children be able to use the mutexes in shared memory
> like this on systems which support pthread_mutexattr_setpshared()?
>
Yes, I think this should work on such a system.
> > Note that you
> > must be very careful about possible deadlocks and freeing resources when
> > using semaphores, but I don't see why they wouldn't work for both
> > threads and processes.
>
> how would you recommend dealing with possible deadlocks? i've tried
> to minimize the time spent and code run in a critical section but
> sometimes things can still go wrong and for example a lock holder
> might be killed which would lead to a deadlock. should somekind of
> lock expiration strategy be implemented?
>
The academicians would say that if there is only one resource that can
be held, then there can be no deadlock. In the real world, however, the
possibility that a lock holder is killed without waking up processes
waiting on the lock is certainly a potential deadock. It's the
programmer's responsibility to make sure that processes clean up after
themselves when exiting, which in this case would include a call to
pthread_mutex_unlock().
I still think, however, that you should consider implementing a solution
that is actually threaded if you want to compare performance. If the
only difference in the two solutions is the mechanism for locking
resources, then you won't see much of a difference in performance.
--
Adam
------------------------------
From: Michael Harvey <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system
Subject: thread timing info, suspending threads
Date: Fri, 15 Jun 2001 12:09:58 -0700
I am working on an application thread scheduler and need to be able to
control how much time a given thread will spend working. To accomplish
this I need to be able to find out how much time it has used (preferably
with nanosecond resolution), and I also need to be able to suspend a
thread and resume it later.
In Win32 (yes this is cross platform) I use GetThreadTimes() to get
kernel and user times, and SuspendThread()/ResumeThread() to turn it on
and off.
Does similar functionality exist in pthreads, or if not, is there a
LinuxThreads workaround that can do it?
Thanks,
Mike
------------------------------
From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: sharing Pthread mutexes among processes
Date: Fri, 15 Jun 2001 15:38:31 +0000
Ken Whaley wrote:
>
> pthreads-the-standard specifices PTHREAD_PROCESS_SHARED
> (as an option?), but linuxthreads-the-implementation currently does
> not support PTHREAD_PROCESS_SHARED.
>
"pthread-the-standard" is POSIX 1003.1c, and yes,
_POSIX_THREAD_PROCESS_SHARED is an option. If
_POSIX_THREAD_PROCESS_SHARED is defined by <unistd.h>, then
pthread_mutexattr_setpshared() must be implemented. Since
_POSIX_THREAD_PROCESS_SHARED is not defined for Linux, Linux complies
with the standard in this regard.
--
Adam
------------------------------
From: "Timur Aydin" <[EMAIL PROTECTED]>
Subject: Ending thread blocked in I/O
Date: Fri, 15 Jun 2001 15:54:02 -0400
Hello everybody,
My application has a thread that is blocked in an ioctl call to a kernel
mode driver, waiting for an event to occur. When the event occurs, the
kernel will unblock the process and the same loop will start again. How can
end this thread? Is there a generic method that works for both Linux and
Win32?
Timur.
------------------------------
From: [EMAIL PROTECTED] (quux111)
Subject: Re: kylix
Date: 15 Jun 2001 18:54:06 GMT
"Timur Aydin" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Sir, if you had looked at the borland website, you would have realized
> that kylix is not free software.
>
> Timur.
>
> "filipe" <[EMAIL PROTECTED]> wrote in message
> news:9gd089$i4k$[EMAIL PROTECTED]...
>> i need to find the download of kylix.
>>
>>
>
It is in fact very *expensive* software -- $999 for a single-seat developer
license was the last figure I heard, which puts this package firmly outside
the range of most developers I know. The high price, plus the fact that
relatively few people in the Linux space use Pascal (especially the weird
Borland dialect), almost guarantees that Kylix will have little
penetration.
Borland seems to be hoping that there is some huge but silent group of
Delphi coders who desperately want to move to Linux. I think they're wrong
-- it would have made more sense to release C++ Builder first and *then*
Kylix/Delphi, but then Borland's leading-lights are all Pascal fans....
Digression: The core library of both Delphi and C++ builder, the VCL, is
written in Object Pascal. This means it is an absolute grotendous pain in
the ass when used with C++, not to mention butt-slow. But that is a rant
for another day....
Regards,
quux111
------------------------------
From: Jeremy D. Mullin <[EMAIL PROTECTED]>
Subject: creating a large file on ext2 fs
Date: 15 Jun 2001 20:34:40 GMT
If I run the program included below on my Red Hat 7.1 machine (2.4
kernel) and attempt to create a large file the file always grows to
2147000086 bytes and then lseek64 returns an "invalid argument" error.
There aren't any disk quotas set up. Anybody know what I'm doing wrong?
My guess is the code is correct, but I'm just running into some hardware
limitation?
The disk itself is only 1.5 gig, but linux seems to be good at knowing
that I'm only writing a few bytes here and there, and doesn't actually
use up 2147000086 bytes on disk. (windows, on the other hand, does just
that when I try it).
TIA,
J.D.
#define _LARGEFILE64_SOURCE
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
int main( void )
{
int retval;
int file;
loff_t offset;
int i;
file = open64( "testfile", O_RDWR );
if ( file < 0 )
{
perror( "open" );
return 1;
}
for ( i = 1; i < 3000; i++ )
{
printf( "." );
offset = i * 1000000;
retval = lseek64( file, offset, SEEK_SET );
if ( retval == -1 )
{
perror( "llseek" );
return 1;
}
retval = write( file, "hi", 2 );
if ( retval != 2 )
{
perror( "write" );
return 1;
}
}
close( file );
return 0;
}
------------------------------
From: nordi <[EMAIL PROTECTED]>
Subject: Re: creating a large file on ext2 fs
Date: Fri, 15 Jun 2001 22:57:42 +0200
Jeremy D. Mullin wrote:
> If I run the program included below on my Red Hat 7.1 machine (2.4
> kernel) and attempt to create a large file the file always grows to
> 2147000086 bytes and then lseek64 returns an "invalid argument" error.
According to one of my books, the maximum size for a file on an ext2
partition is 16GB. BUT the maximum size for a partition is only ...
surprise... 2GB. So I guess the ext2 specs simply don't allow it.
nordi
--
Linux - Less bugs for less bucks!
Visit http://private.addcom.de/nordi
------------------------------
From: Chris Cox <[EMAIL PROTECTED]>
Subject: Re: creating a large file on ext2 fs
Date: Fri, 15 Jun 2001 21:13:29 GMT
Eeek... get a different book...
http://www.linuxdoc.org/HOWTO/Filesystems-HOWTO-6.html
The comment about files going to 16GB.. where did they
get that?? Looks like a mistake from an older book (where
the kernel vfs may have limited the partition size to 2G).
Obviously, things have changed and there aren't nearly
as many limitations.. however, getting large files
to work takes some setup.
Partitions to 16TB with ext2... files to 2^63 bytes with
the LFS (in the 2.4 kernel) and a new enough glibc.
I don't think there's a LFS HOWTO out there (?) however.
Of course, it may not be needed nowadays... just a kernel
option now I guess.
nordi wrote:
>
> Jeremy D. Mullin wrote:
>
> > If I run the program included below on my Red Hat 7.1 machine (2.4
> > kernel) and attempt to create a large file the file always grows to
> > 2147000086 bytes and then lseek64 returns an "invalid argument" error.
>
> According to one of my books, the maximum size for a file on an ext2
> partition is 16GB. BUT the maximum size for a partition is only ...
> surprise... 2GB. So I guess the ext2 specs simply don't allow it.
>
> nordi
>
> --
> Linux - Less bugs for less bucks!
>
> Visit http://private.addcom.de/nordi
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: getopt + optional parameter
Date: Fri, 15 Jun 2001 22:24:58 GMT
Felix Natter <[EMAIL PROTECTED]> wrote:
> Micah Cowan <[EMAIL PROTECTED]> writes:
>> Felix Natter <[EMAIL PROTECTED]> writes:
>>
>> > hi,
>> >
>> > I usually use optarg to get a required parameter for an option,
>> > but if I declare an option with an optional argument (i.e. "c::"),
>> > optarg is NULL even if an argument is specified.
>> >
>> > Is there another way to get an argument for an option
>> > (optarg is a GNU extension anyway) ?
>>
>> AIUI, not optarg but the optional argument "c::" syntax is a GNU
>> extension. And optarg works fine for me - can you post the relevant
>> argument-parsing portion of the offending code and the command line
>> you're using?
>
> Thanks, I misunderstood this.
> optarg didn't seem to work together with the optional argument syntax
> (optarg was NULL even if an option was specified), but since that is a GNU
> extension, I'm not going to use it anyway.
> But is there a way to use options which take an optional argument without
> using the GNU extension ?
> --
> Felix Natter
My experience with optional args say "x::", was that -xoptarg worked,
whereas -x optarg returns null.
Jerry
------------------------------
From: Oliver Kowalke <[EMAIL PROTECTED]>
Subject: problem with select() function ?!
Date: Sat, 16 Jun 2001 01:03:47 +0200
Reply-To: [EMAIL PROTECTED]
Hello,
I've a problem with the select() function. Maybe I did someting wrong (I
followed the instructions by 'UNIX network programing, Vol. 1' from
R.W.Stevens).
the problem:
The descriptor of a connected socket (returned by accept() function) is
marked as readable by select() after(!!!) a read() from this descriptor.
I thought that select() should indicate that the descriptor is readable
only if the remote client writes some additional bytes to the socket.
Something is wrong.
Could you give me some hints, please.
with regards,
Oliver
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-Apps Digest
******************************
