[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    [jazepeda@pacbell.net: Re: here's something silly for kmimetype]
From:       Alex Zepeda <jazepeda () pacbell ! net>
Date:       2002-02-09 5:38:09
[Download RAW message or body]

----- Forwarded message from Alex Zepeda <jazepeda@pacbell.net> -----

Date: Fri, 8 Feb 2002 20:14:36 -0800
From: Alex Zepeda <jazepeda@pacbell.net>
To: Will Andrews <will@csociety.org>, kde-freebsd@lists.csociety.org
Subject: Re: here's something silly for kmimetype
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20020208154050.GY82640@squall.waterspout.com>; from will@csociety.org \
on Fri, Feb 08, 2002 at 10:40:50AM -0500

On Fri, Feb 08, 2002 at 10:40:50AM -0500, Will Andrews wrote:

> > If you're at all familiar with the way POSIX.1e ACLs are implemented on
> > FreeBSD, you've met the nifty UFS extended attributes bits.  This patch
> > allows one to set an attribute in the system namespace named "mimetype",
> > and this will override anything else if present.  Sorta like BeOS.

s/\/usr3/\[VOLUME\]/g

> > Assuming you've got a -current box with a volume /usr3 and you've already
> > setup ACLs on it, you'd just need to execute the following commands to
> > enable the mimetype attribute:
> > 
> > extattrctl initattr 256 [VOLUME]/.attribute/system/mimetype
> > extattrctl enable [VOLUME] system mimetype [VOLUME]/.attribute/system/mimetype
> > 
> > From there you can use the commandline utility setextattr to tweak the 
> > mimetype like so:
> > 
> > setextattr system mimetype /usr3/test inode/directory
> > 
> > And KDE should recognize it as a directory no matter what.
> > 
> > Have fun,
> > 
> > - alex

> My only comment on the below patch is that the __FreeBSD__ check
> may be wrong.  But I can't think of a better one, since the
> extattr.h on another system might have an entirely different API,
> and this is the easier hack.  Or does posix(1e) require this
> particular API?

Maybe, maybe not.  This was a 15 minute effort, tops.  I haven't tested it
(haven't gotten Qt compiled yet).  A quick search revealed that Irix and
one or two other unicies support extended attributes, quite possibly with
a similar api.

I highly doubt that POSIX requires the extended attribute API since there
are for sure filesystems that support ACLs natively.

I've already had some licensing disputes with KDE in the past, so I'm not
too quick to write a nifty GUI wizard to setup this stuff on fbsd...  
likewise portibility wasn't a goal here either.  Feel free to screw around
with it to make it work tho (I'd highly recommend removing the extended
attribute bits from kmimetype and defining a whole new class or extending
for instance KFile..).

- alex

> > Index: kmimetype.cpp
> > ===================================================================
> > RCS file: /home/kde/kdelibs/kio/kio/kmimetype.cpp,v
> > retrieving revision 1.148
> > diff -b -d -u -1 -r1.148 kmimetype.cpp
> > --- kmimetype.cpp	2002/01/27 00:53:12	1.148
> > +++ kmimetype.cpp	2002/02/08 04:41:43
> > @@ -25,2 +25,7 @@
> > 
> > +#ifdef __FreeBSD__
> > +	#include <sys/uio.h>
> > +	#include <sys/extattr.h>
> > +#endif
> > +
> > #include <assert.h>
> > @@ -58,2 +63,6 @@
> > 
> > +#ifdef __FreeBSD__
> > +#include <string.h>
> > +#endif
> > +
> > template class KSharedPtr<KMimeType>;
> > @@ -159,2 +168,21 @@
> > _is_local_file = true;
> > +
> > +#ifdef __FreeBSD__
> > +  // Check the extended attributes first
> > +  // this is quick and painless
> > +  if (_is_local_file) {
> > +    struct iovec iov_buf;
> > +    char buf[256];
> > +
> > +    iov_buf.iov_base = buf;
> > +    iov_buf.iov_len = 256;
> > +
> > +    memset(buf, 0, 256);
> > +
> > +    ret = extattr_get_file(QFile::encodeName(path), EXTATTR_NAMESPACE_SYSTEM, \
> > "mimetype", &iov_buf, 1); +    if (ret != -1) {
> > +      return mimeType(buf);
> > +    }
> > +  }
> > +#endif
> > 
> 
> 
> -- 
> wca

----- End forwarded message -----


[prev in list] [next in list] [prev in thread] [next in thread]