UserlandFS update

Howdy,

to those using my UserlandFS package to create Haiku images, please note, 
that I just updated the it, due to a now fixed bug that could take you to 
KDL when trying to mount a volume. My thanks go to Jérome Duval for 
reporting the problem.

The updated package can be found at the old location:

  http://tfs.cs.tu-berlin.de/~bonefish/download/userlandfs.zip

CU, Ingo

Re: struct stat st_mode bits

> "François Revol" <revol@...> wrote:
> > > BFS could use this internally, and although the original one 
> > > doesn't, 
> > > my implementation actually does. It's not really needed though, 
> > > so 
> > > we 
> > > could think about removing it.
> > Doesn't tell me what it does...
> 
> Ah, okay. I should have said if the directory/container in question 
> supports duplicate entries or not. For indices this is generally 
> true, 
> for other types, it's not :)
> 
> > > > Also I'd reconsider using S_FOO_INDEX in favor of S_INDEX, 
> > > > since 
> > > > it's not very scalable... we have only 2 bits left in that 
> > > > field.
> > > I don't understand what you're trying to say here.
> > Are the different bits really needed or could we use just one to 
> > say 
> > S_INDEX without type distinction ?
> 
> They are actually used by BFS to maintain the index type. Although it 
> also duplicates this information in the B+tree header, we now also 
> use 
> it to report the types when calling stat() on an index.
> 
Or what about using the bits as value instead of bitmask ? would give 
more room,

Re: struct stat st_mode bits

François Revol wrote on Wed, 01 Dec 2004 23:29:32 +0100 CET:
> Or what about using the bits as value instead of bitmask ? would give 
> more room, S_IFMT does it (see LNK, and SOCK... wait, where are my
> sockets gone ?

And for other future file system object types, like things which are a bit
like a MacOS alias and a bit like a hard link, but also work for directories.

- Alex

Re: struct stat st_mode bits

"François Revol" <revol@...> wrote:
[sys/stat.h, index types]
> > They are actually used by BFS to maintain the index type. Although 
> > it 
> > also duplicates this information in the B+tree header, we now also 
> > use it to report the types when calling stat() on an index.
> well it's a stripped down dupped info from 
> fs_index.h:index_info::type.

It's not stripped down, it represents all types BFS supports.

Bye,
   Axel.

src/kernel/apps/cpuinfo - small fix

Revision 1.37 of OS.h breaks 'cpuinfo' 
(affecting in turn config.x86.ini and the kernel)

src/kernel/apps/cpuinfo/main.c:115: 
structure has no member named `vendorid'

This needs to be changed
memcpy(vendorID, info->eax_0.vendorid, 12);

to this
memcpy(vendorID, info->eax_0.vendor_id, 12);

/Jonas Sundström.              www.kirilla.com

Website down again?

Not been able to contact any of the sites on the osbos.net server all
day with either my normal net or my cellphone (GPRS, real net - not
WAP). Is it down again?

Cian

Cambio di email... =(

A causa di quei simpaticoni della Tin.it, che hanno
segato il mio account email senza nemmeno avvertire, mi trovo
costretto a traslocare su di un nuovo indirizzo:

per questo motivo rimpiazzate il mio vecchio indirizzo
(paolo.pisati <at> tin.it) con il nuovo flag <at> oltrelinux.com

Grazie

-- 
Paolo

Italian FreeBSD User Group: http://www.gufi.org

--

-- 
Regole e consigli per l'uso della lista: http://www.gufi.org/GUFI/mailing_list

queries on missing attributes

Is there a way to make queries on missing attributes? 

A query on foo=* currently excludes the filesystem entries completely 
missing the foo attribute. What I would like is being able to set a 
query to include only entries missing a certain attribute.

Suggested query substring to match entries
missing a certain attribute:   'foo!exist'

I have two queries:

New email
((MAIL:status=="New")
&&(MAIL:classification!="Spam"))

Spam
((MAIL:status=="New")
&&(MAIL:classification=="Spam"))

I'd like being able to have a query for Unclassified email,
which is missing the MAIL:classification attribute.

((MAIL:status=="New")
&&(MAIL:classification!exist))

/Jonas Sundström.               www.kirilla.com

Re: queries on missing attributes

Jonas Sundström wrote on Mon, 20 Dec 2004 14:23:50 +0100 CET:
> Is there a way to make queries on missing attributes?

Since it needs an index to iterate over, you can use the file type to just
check the files you need, or even "name=*" to iterate over all files.  The
query would be something like name=*&&attribute="", but that only works for
strings I think.  Or maybe you could try name=*&&attribute!=*

I added a couple of operators in my RAM file system for testing attribute
existance, <>attribute for files including that attribute, and ><attribute
for ones that don't have it (think of the > and < together making an X shape
to cross out the possibility of existance).  But since the query language
is implemented by each file system (some wasted effort there - the OS should
just provide indices, let library code do queries), those operators are only
in AGMSRAMFileSystem.

- Alex

Re: queries on missing attributes

"Alexander G. M. Smith" <agmsmith@...> wrote:
> Jonas Sundström wrote on Mon, 20 Dec 2004 14:23:50 +0100 CET:
> > Is there a way to make queries on missing attributes?
> 
> Since it needs an index to iterate over, you can use the file type to 
> just
> check the files you need, or even "name=*" to iterate over all files.  
> The
> query would be something like name=*&&attribute="", but that only 
> works for
> strings I think.  Or maybe you could try name=*&&attribute!=*

I was using (name=*)&&(something else) in my testing. IIRC it would 
only return files that had the attribute. I could be wrong though. 
Perhaps there's some boolean logic I haven't tested.

> I added a couple of operators in my RAM file system for testing 
> attribute
> existance, <>attribute for files including that attribute, and ><
> attribute
> for ones that don't have it (think of the > and < together making an 
> X shape
> to cross out the possibility of existance).  But since the query 
> language
> is implemented by each file system (some wasted effort there - the OS 
> should
> just provide indices, let library code do queries), those operators 
> are only
> in AGMSRAMFileSystem.