James Urquhart | 2 Aug 12:29 2007
Picon

BDiskDeviceParameterEditor, BDiskScannerParameterEditor, and PartitioningDialog confusion

Hey there,

I recently fixed up the DriveSetup preferences app a bit ( patch  
located on the trac at http://dev.haiku-os.org/ticket/1347  ), but  
came a bit stuck when i got to shelling out the Partition &  
Initialisation code.

Looking through the Haiku storage kit, i first noticed that  
BPartition exposes code which allows me to obtain a  
BDiskDeviceParameterEditor, via any of four functions:

status_t BPartition::GetParameterEditor(BDiskDeviceParameterEditor  
**editor)
status_t BPartition::GetContentParameterEditor 
(BDiskDeviceParameterEditor **editor)
status_t BPartition::GetInitializationParameterEditor(const char  
*system, BDiskDeviceParameterEditor **editor) const
status_t BPartition::GetChildCreationParameterEditor(const char  
*system,	BDiskDeviceParameterEditor **editor) const

Sad to say, i am left clueless as to which one of these functions i  
should use for which circumstance - i thought the original DriveSetup  
only had parameter editor's for partitioning and initialising file  
systems?

This confusion is further compounded by the fact that nobody seems to  
have implemented BDiskDeviceParameterEditor. Yikes!

Looking a bit further, i found this rather interesting  
PartitioningDialog class, which seemed to require a  
(Continue reading)

Waldemar Kornewald | 27 Feb 15:09 2007

list admin

Hi,
could the list admin please contact me, privately? Thanks!

Bye,
Waldemar Kornewald

Fredrik Ekdahl | 4 Mar 14:49 2006
Picon

Mime types

Hi
I've done some mime types in rdef format. Hope its useful. There are sniff rules for some of them. They are untested but I hope it is correct. The files are in the attached file mime.zip.
 
Fredrik Ekdahl
Attachment (mime.zip): application/zip, 30 KiB
Axel Dörfler | 15 Jan 15:12 2005
Picon

Problems with ResourceFile

Hi there,

when running a few apps on Haiku natively, I get frequent crashes 
somewhere in the private ResourceFile class. It doesn't happen all the 
time, though, sometimes it runs through without any problems (the 
"translate" command). The error goes away (of course), when I remove 
the BAppFileInfo construction in the BApplication constructor.

When I start the media_server, the media_addon_server always crashes in 
that class - obviously because it's using the resources beyond the 
BApplication constructor (commenting out BAppFileInfo doesn't help 
there).

I am not sure if this class is to blame as it looks correct, but 
something seems to be broken. Has it been tested with MALLOC_DEBUG 
turned on already?

Bye,
   Axel.

Oliver Tappe | 27 Jul 21:52 2004
Picon

libstdc++.r4.so

Hi there,

I have been wrestling with the OBOS^H^H^H^HHaiku-provided libcppunit.so for 
several days only to find out that the crashes I observed were in fact 
caused by the buggy std::string implementation living in libstdc++.r4.so.
If anyone is interested, I have a small testprogram that exposes the bug(s) 
(on my machine).

Googling the net for more info on this didn't bring up much, but brought me 
here instead, to throw my 2cw into the discussion:

I learned from the archives that Haiku doesn't yet have libstdc++.r4.so but 
needs one, as several parts are already using it. This lib must be binary 
compatible with the one from R5. Someone mentioned that the source for the 
R5-version isn't available, but I wonder if this really is true. I (maybe 
naively) think that libstdc++.r4.so is just a collection of template 
instantiations, so the source is actually found in the headers...

If that's true, it should be possible to recreate the library like this:
1. find out which templates are actually contained in libstc++.r4.so
2. write a little tool that explicitly instantiatiates all the required 
   templates, and bundles them into a lib.

During my tests, I have found out that Zeta (maybe Dano, too) provides a 
different libstc++.r4.so, which contains a fixed std:string implementation. 
Surprisingly, the Zeta-version seems to contain a different set of 
template-instantiations, as I needed to relink to get my testprograms 
started.

During the next days, I will try to find out the exact differences between 
these two libraries and I will check if there's a way to extract a lib from 
the Zeta-(STL-)headers that is binary compatible with (but not as bad as) 
the R5-version.

Please shout if this is pointless...

cheers,
	Oliver

Axel Dörfler | 26 Jun 16:36 2004
Picon

Getting rid of kernel_interface.POSIX.cpp

Hi there,

I am currently in the process of making our libbe.so replacement to 
work on top of the new kernel, or rather investigating what needs to be 
done to do so.

While kernel_interface.POSIX.cpp (and the general approach behind it) 
is very useful for porting, is it planned to get rid of that extra 
level of indirection one day?

Also, we don't yet have a libstdc++ - and yet, unlike the original 
libbe.so, we have several components using it (IIRC only the sniffer in 
the storage kit). It would have been great if someone had thought about 
this particular dependency earlier...

Speaking of the Sniffer - what does it do there? I thought it was part 
of the Registrar and only used by the storage kit? Or is it common to 
both?

Bye,
   Axel.

Axel Dörfler | 10 Mar 02:42 2004
Picon

BNodeInfo::GetTrackerIcon()

Hi there,

I had a look at the above mentioned function, and I think it's not 
working correctly in all cases; I see the culprit in this part:

	if (GetType(mimeString) != B_OK) {
		// no type available -- get the "application/octet-stream" icon
		BMimeType type("application/octet-stream");
		error = type.GetIcon(icon, k);
		success = (error == B_OK);
	}

First, the generic MIME type is also defined as a constant, but it 
shouldn't be taken for all files. Instead, it should be differentiated 
by file type. I.e. it should take "application/x-vnd.Be-directory" for 
directories, "application/x-vnd.Be-volume" for volumes, etc.
BTW for a list of these types, have a look at:
http://cvs.sourceforge.net/viewcvs.py/opentracker/opentracker/tracker/MimeTypes.h?rev=1.1.1.1&view=auto

I also think that we should put those into the public headers as well 
(matching the B_FILE_MIME_TYPE constant).

Bye,
   Axel.

Axel Dörfler | 8 Mar 18:33 2004
Picon

BVolume::SetName()

Hi there,

I just realized that the original BVolume::SetName() will change the 
name of the mount point with the volume name, while ours does not.
I.e. if you change "data" to "video data", the mount point at "/data" 
will be renamed to "/video data".

Bye,
   Axel.

Andrew Bachmann | 30 Jan 06:35 2004
Picon

stat weirdness

Hello all,

I found this weirdness while using stat in beos R5, on a bfs partition.  I thought it might be of 
interest to some.

I was downloading a file in beshare.  While doing this I ran stat on the file, in a tight loop.  I 
checked for changing size and changing modification time.  Specifically, I checked to see if the 
size changed without the modification time changing, and vice versa.

I expected to see one of two things.  The first possibility was that they always get updated 
atomically, and one never changes without the other.  The second possibility was that one was 
updated before the other, and I presumed that it would always be the same field updated.

For the most part, the fields are updated together, but occasionally they are not.  When they are 
not the resulting stat has an st_size of zero.  This is despite the fact that the file obviously has 
several megabytes of data.  I think this is a property of R5 bfs implementation, although it could 
be someplace else.  I hope that this property doesn't live in our openbfs implementation. :-)

Here's the test (extra stuff trimmed):

int main() {
  int fd = open("filename", O_RDONLY);
  struct stat st;
  off_t osize;
  time_t otime;
  while (true) {
	osize = st.st_size;
    otime = st.st_mtime;
    fstat(fd, &st);
	if ((osize != st.st_size) && (otime == st.st_mtime) ||
        (osize == st.st_size) && (otime != st.st_mtime)) {
		fprintf(stderr, "mismatch: ");
		fprintf(stderr, "os = %lu, ns = %lu : ", osize, st.st_size);
		fprintf(stderr, "ot = %lu, nt = %lu\n", otime, st.st_mtime);
    }
}

Andrew

Tyler Dauwalder | 28 Oct 20:57 2003
Picon

Re: ddm questions

On 2003-10-27 at 15:09:46 [-0800], you wrote:
> 
> On 2003-10-27 at 23:33:37 [+0100], you wrote:
> > > > > > BTW, do you think B_OS_NAME_LENGTH (32 chars) is sufficient for
> > > > > > partition
> > > > > > (content) names?
> > > > > 
> > > > > That's where volume names end up getting stored, isn't it? No, I 
> > > > > don't
> > > > > like
> > > > > the 32 character limit for the volume names. Seems okay for the
> > > > > disk-system
> > > > > type names, though.
> > > > 
> > > > You mean the ones defined in <DiskDeviceTypes.h>? The longest one
> > > > already
> > > > occupies 28 characters. Maybe it's better to have some more margin?
> > > 
> > > Yikes. Okay, maybe so. I'll switch those, too.
> > 
> > Okay, is there a difference between disk system names and partition types?
> > Are the disk system names the short ones, like 'bfs' and 'iso9660', or
> > should
> > we make those B_FILE_NAME_LENGTH as well?
> 
> Since the disk systems are provided as modules, their names are module 
> names,
> i.e. `filesystems/bfs/v1' or `partitioning_systems/intel/extended/v1'. They
> should at least be B_FILE_NAME_LENGTH or even B_PATH_NAME_LENGTH.

Okay, I switched them to B_PATH_NAME_LENGTH.

-Tyler

Ingo Weinhold | 28 Oct 00:09 2003
Picon

Re: ddm questions


On 2003-10-27 at 23:33:37 [+0100], you wrote:
> > > > > BTW, do you think B_OS_NAME_LENGTH (32 chars) is sufficient for
> > > > > partition
> > > > > (content) names?
> > > > 
> > > > That's where volume names end up getting stored, isn't it? No, I don't
> > > > like
> > > > the 32 character limit for the volume names. Seems okay for the
> > > > disk-system
> > > > type names, though.
> > > 
> > > You mean the ones defined in <DiskDeviceTypes.h>? The longest one 
> > > already
> > > occupies 28 characters. Maybe it's better to have some more margin?
> > 
> > Yikes. Okay, maybe so. I'll switch those, too.
> 
> Okay, is there a difference between disk system names and partition types?
> Are the disk system names the short ones, like 'bfs' and 'iso9660', or 
> should
> we make those B_FILE_NAME_LENGTH as well?

Since the disk systems are provided as modules, their names are module names, 
i.e. `filesystems/bfs/v1' or `partitioning_systems/intel/extended/v1'. They 
should at least be B_FILE_NAME_LENGTH or even B_PATH_NAME_LENGTH.

CU, Ingo


Gmane