From jitendra.moon@wipro.com Sun Jan 4 04:11:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by mail.gnome.org (Postfix) with ESMTP id 4E185185D5 for ; Sun, 4 Jan 2004 04:11:51 -0500 (EST) Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i049BnOZ025386 for ; Sun, 4 Jan 2004 14:41:49 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Sun, 04 Jan 2004 14:42:58 +0530 Received: from chn-snr-bh3.wipro.com ([10.145.50.93]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from hyd-mdp-msg.wipro.com ([10.150.50.99]) by chn-snr-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from mdpnok109242 ([192.168.142.126]) by hyd-mdp-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Reply-To: From: "Jitendra Moon" To: Date: Sun, 4 Jan 2004 14:46:14 +0530 Message-ID: <000601c3d2a3$67495ff0$b786a8c0@mdpnok109242> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3D2D1.81019BF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 04 Jan 2004 09:11:48.0301 (UTC) FILETIME=[C8450FD0:01C3D2A2] Subject: (no subject) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 I have installed gnome-vfs-2.0 on my debian box. Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs API=92s. Any sample code in this regard will be of great help. =20 Are only gnome vfs libraries sufficient to access above mentioned device file systems on debian Linux? Or do we need to install some thing more on top of gnome VFS? =20 Again any sample code will be of great help. =20 =20 =20 Jitendra Moon =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I have installed gnome-vfs-2.0 on my debian = box.

Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs = API’s.

Any sample code in this regard will be of great = help.

 

Are only gnome vfs libraries sufficient to access = above mentioned device file systems on debian = Linux?

Or do we need to install some thing more on top of = gnome VFS?

 

Again any sample code will be of great = help.

 

 

 

Jitendra Moon

 

 

 

 

 

 

 

 

 

 

 

 

 

------=_NextPart_000_0007_01C3D2D1.81019BF0-- From ejk@ucsc.edu Fri Jan 2 17:47:02 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by mail.gnome.org (Postfix) with ESMTP id EF43B18448; Fri, 2 Jan 2004 17:47:01 -0500 (EST) Received: from [169.233.37.23] (k-d0789.resnet.ucsc.edu [169.233.37.23]) by ucsc.edu (8.10.1/8.10.1) with ESMTP id i02MhLx01991; Fri, 2 Jan 2004 14:43:23 -0800 (PST) Subject: Re: Suggestion for file type detection approach From: Edward Jay Kreps Reply-To: Suggestion.for.file.type.detection.approach@ucsc.edu To: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org, gnome-vfs-list@gnome.org Content-Type: text/plain Message-Id: <1073083582.3530.77.camel@whipple> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 14:46:22 -0800 Content-Transfer-Encoding: 7bit X-UCSC-CATS-MailScanner: Found to be clean X-UCSC-CATS-MailScanner-SpamCheck: Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: >Given the performance bottleneck imposed by sniffing, I suggest that it >is not used anymore in directory listing routines. It should be used >when the user tries to open an unknown file. Let's imagine this case: I don't think this is a good way of thinking about things. The questions are: 1. Is sniffing a good idea? 2. If so does it work correctly? 3. If (1) and (2), is it performing fast enough? I think others have argued persuasively that sniffing is a good idea since unix doesn't generally give file name suffixes to files (even though gnome does), and often files have incorrect suffixes. A number of people have said that there are instances where sniffing is not correctly determining the file type. If true, this is an excellent argument for fixing those cases, but not at all an argument for throwing away sniffing altogether. >From your benchmarking it is clear that (3) is a problem, and sniffing is taking too long. This is not an argument for getting rid of it though, just an argument for speeding it up. Someone suggested running it through a profiler, but I doubt that will be worthwhile--the problem is almost certainly the multiple disk accesses (your disk is having to seek for each file). As others have pointed out, a two pass technique. based on extension and then sniffing is also a bad idea since icons, etc would change in the case of a discrepancy. Sniffing is slow because it opens every file and reads some of it every time you open a given directory. If you want to make this fast, cache filetypes; now opening the huge mp3 folder is just a matter of reading a single cache file and sniffing those files with a modification time later than that of the cache file. Naturally this would only need to be done for those really huge directories, it would probably be a waste for directories with only a hundred files or fewer. I don't think we need to worry about which approach is ultimately going to perform faster. For a program like Nautilus either there is or is not a human-noticeable lag time; improving performance when there is no lag time is totally pointless. A number of people have used Windows as an example of why we don't need to sniff files; though there are a number of features in Windows worth copying this is definitely not one of them. I have worked on some commercial software and the number one frivolous bug report or unfixable user issue occurs when the user attempts to open a file that has an incorrect filename extension. People on this list have suggested that this is a user problem not a software problem (i.e. that the user was stupid and beyond help), but I can assure you that however obvious the connection between the hidden Windows filename extension and the error message that our program gave is to me and you, it was not obvious to a large number of otherwise very intelligent people who just weren't as knowledgeable about computers. People always think that the icon for a file is somehow part of the file (it makes sense if you don't think about it too hard), and so if a file has, say, a jpeg icon it doesn't occur to them that it is not a jpeg. -Jay From dionney@hotmail.com Fri Jan 2 19:58:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from dionney.dyndns.org (modemcable253.38-203-24.mc.videotron.ca [24.203.38.253]) by mail.gnome.org (Postfix) with ESMTP id B0854182E2; Fri, 2 Jan 2004 19:58:08 -0500 (EST) Received: from [127.0.0.1] (dionney.dyndns.org [127.0.0.1]) by dionney.dyndns.org (Postfix) with ESMTP id F2F9CFD65; Fri, 2 Jan 2004 19:57:59 -0500 (EST) Subject: Re: Suggestion for file type detection approach From: Yves Dionne To: gnome-vfs-list@gnome.org Cc: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1072403221.945.61.camel@hermes.intra.gs2.com.br> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> Content-Type: multipart/mixed; boundary="=-uazmxkOo5iyZC9kUE0ez" Message-Id: <1073091476.23189.12.camel@dionney.dyndns.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 19:57:58 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-uazmxkOo5iyZC9kUE0ez Content-Type: text/plain; charset= Content-Transfer-Encoding: 8bit On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > Why not support recording the mime-type of a file as meta-data (EA) on > > filesystems that support it (every one of them at this point?). It > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > to clearly be the right way to do it. If GNOME VFS supported it then > > it seems it would be easy to implement for alot of applications. > > > > I agree with you, but while we must provide a quick solution, EA (and > the attributes themselves) must be standardized cross-unix and > cross-desktop. This will take some time to mature, since the mechanisms > for sending files through the Internet (between computers, in general) > must mature to support EA. I never used Apple operating systems, but it > looks like they have such a mechanism. Nothing that a tar with EA > support could not do. > > GNOME must provide room today to support state-of-the-art technologies > in the future, but must at the same time provide solutions to today's > users using today's technologies. > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. I thought this could be fun, so hacked gnome-vfs to save the mime type on a EA named "mime_type". When trying to find the mime type for the file, gnome-vfs will first check if this EA exists. If so, use that for the mime type. If not, determine the mime type as usual and save it. It works only for local files. If you don't have permission to change the file, the EA will not be saved. And you need a file system which support EA, of course. I tested it with ext3. Might work with others too. This is a hack, just an exercise to see if it could be beneficial. I did this just for fun. I did not try to follow coding standards, I have no intention of maintaining this patch. Although I might try to hack nautilus to allow changing the mime type (as recorded in the EA). The following patch is against gnome-vfs-2.4.1 as found in Fedora. I attach also a modified SPEC file, just in case someone wants to build it. --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs-2.4.1-attr.patch Content-Type: text/x-patch; name=gnome-vfs-2.4.1-attr.patch; charset= Content-Transfer-Encoding: 7bit diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h gnome-vfs-2.4.1/acconfig.h --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h 2003-09-27 11:42:49.000000000 -0400 +++ gnome-vfs-2.4.1/acconfig.h 2004-01-02 17:11:36.665008680 -0500 @@ -15,6 +15,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in gnome-vfs-2.4.1/config.h.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in 2003-09-01 14:32:48.000000000 -0400 +++ gnome-vfs-2.4.1/config.h.in 2004-01-02 17:11:36.667008376 -0500 @@ -16,6 +16,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in gnome-vfs-2.4.1/configure.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in 2003-10-12 06:51:55.000000000 -0400 +++ gnome-vfs-2.4.1/configure.in 2004-01-02 17:11:36.671007768 -0500 @@ -482,6 +482,22 @@ +dnl *********************** +dnl *** Checks for ATTR *** +dnl *********************** + +ATTR_MISSING_WARNING="Gnome-vfs depends on ATTR" +ATTR_LIBS= +AC_CHECK_LIB(attr, attr_getf, + [AC_CHECK_HEADERS(attr/attributes.h, + [AC_DEFINE(HAVE_ATTR) + ATTR_LIBS="-lattr"], + AC_MSG_WARN(*** ATTR support will not be built (header files not found) $ATTR_MISSING_WARNING ***))], + AC_MSG_WARN(*** ATTR support will not be built (ATTR library not found) $ATTR_MISSING_WARNING ***)) +AC_SUBST(ATTR_LIBS) + + + dnl ************************** dnl *** Checks for gtk-doc *** dnl ************************** diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2003-09-27 11:42:51.000000000 -0400 +++ gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2004-01-02 17:15:50.041489600 -0500 @@ -39,6 +39,9 @@ #include #include #include +#ifdef HAVE_ATTR +#include +#endif static gboolean module_inited = FALSE; @@ -80,6 +83,40 @@ #endif /* G_LOCK_DEFINE_STATIC */ +#ifdef HAVE_ATTR +static GList *mime_attr = NULL; + +static const char * +get_mime_from_ea (FILE *file) +{ + char * mime_type = NULL; + char * buffer = g_alloca (256+1); + GList * p; + int len = 256; + + if (attr_getf (fileno (file), "mime_type", buffer, &len, 0) == 0) { + buffer[len] = 0; + G_LOCK (mime_mutex); + p = g_list_find_custom (mime_attr, buffer, g_ascii_strcasecmp); + if (p != NULL) { + mime_type = p->data; + } else { + mime_type = g_strdup (buffer); + mime_attr = g_list_insert_sorted (mime_attr, mime_type, g_ascii_strcasecmp); + } + G_UNLOCK (mime_mutex); + } + return mime_type; +} + +static void +set_mime_from_ea (FILE *file, const char *mime_type) +{ + int len = strlen (mime_type); + + attr_setf (fileno (file), "mime_type", mime_type, len, 0); +} +#endif static char * get_priority (char *def, int *priority) @@ -337,6 +374,13 @@ g_list_free (mime_regexs [i]); mime_regexs [i] = NULL; } +#ifdef HAVE_ATTR + for (p = mime_attr; p != NULL; p = p->next) { + g_free (p->data); + } + g_list_free (mime_attr); + mime_attr = NULL; +#endif } static void @@ -714,11 +758,22 @@ } if (file != NULL) { +#if HAVE_ATTR + result = get_mime_from_ea (file); + if (result == NULL) + { +#endif buffer = _gnome_vfs_mime_sniff_buffer_new_generic (file_seek_binder, file_read_binder, file); result = _gnome_vfs_get_mime_type_internal (buffer, path); gnome_vfs_mime_sniff_buffer_free (buffer); +#ifdef HAVE_ATTR + if (result != NULL) { + set_mime_from_ea (file, result); + } + } +#endif fclose (file); } else { result = _gnome_vfs_get_mime_type_internal (NULL, path); diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am gnome-vfs-2.4.1/libgnomevfs/Makefile.am --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:10:48.860276104 -0500 +++ gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:11:36.679006552 -0500 @@ -37,6 +37,7 @@ libgnomevfs_2_la_LIBADD = \ $(LIBGNOMEVFS_LIBS) \ + $(ATTR_LIBS) \ $(NULL) libgnomevfs_2_la_LDFLAGS = \ --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs2.spec Content-Type: text/plain; name=gnome-vfs2.spec; charset= Content-Transfer-Encoding: 8bit %define libbonobo_version 2.2.0 %define gconf2_version 1.2.0 %define gtkdoc_version 0.9 %define gnome_mime_data_version 2.0.0-11 %define redhat_menus_version 0.30 %define po_package gnome-vfs-2.0 Summary: The GNOME virtual file-system libraries. Name: gnome-vfs2 Version: 2.4.1 Release: 1 License: LGPL Group: System Environment/Libraries Source: gnome-vfs-%{version}.tar.bz2 Source2: vfolder-desktop-method.c Source3: desktop-method.c URL: http://www.gnome.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-root Requires: gnome-mime-data >= %{gnome_mime_data_version} Requires: redhat-menus >= %{redhat_menus_version} BuildRequires: libbonobo-devel >= %{libbonobo_version} BuildRequires: GConf2-devel >= %{gconf2_version} BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: bonobo-activation-devel, glib2-devel, libxml2-devel, zlib-devel BuildRequires: popt, bzip2-devel, ORBit2-devel, XFree86-devel, openjade BuildRequires: pkgconfig BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: /usr/bin/automake-1.4 BuildRequires: gtk-doc >= %{gtkdoc_version} Prereq: GConf2 >= %{gconf2_version} Patch1: gnome-vfs-1.9.4.91-docdir.patch Patch2: gnome-vfs-2.1.3-moved-menu-files.patch Patch3: gnome-vfs-2.0.4-onlyshowin.patch Patch5: gnome-vfs-1.9.16-moved-menu-files.patch Patch6: gnome-vfs-2.0.1-only-show-in.patch Patch7: gnome-vfs-2.3.7-modules-conf.patch Patch8: gnome-vfs-2.0.2-newstat.patch Patch9: gnome-vfs-2.0.2-read-only.patch ## this is the automake-requiring patch Patch10: gnome-vfs-2.1.6-old-modules.patch Patch11: gnome-vfs-2.1.6-network-uri.patch Patch12: gnome-vfs-2.1.6-never-show-if-empty.patch Patch13: gnome-vfs-2.1.6-hide-with-empty-subfolders.patch Patch14: gnome-vfs-2.1.6-no-private-methods.patch Patch15: gnome-vfs-2.2.0-vfolder-hacks.patch Patch16: gnome-vfs-2.4.1-attr.patch %description GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for file systems, http, ftp, and others. It provides a URI-based API, backend supporting asynchronous file operations, a MIME type manipulation library, and other features. %package devel Summary: Libraries and include files for developing GNOME VFS applications. Group: Development/Libraries Requires: %{name} = %{version} Requires: GConf2-devel >= %{gconf2_version} Requires: libbonobo-devel >= %{libbonobo_version} Conflicts: bonobo-devel < 1.0.8 Conflicts: gnome-vfs-devel < 1.0.2 %description devel This package provides the necessary development libraries for writing GNOME VFS modules and applications that use the GNOME VFS APIs. %prep %setup -q -n gnome-vfs-%{version} cp -f %{SOURCE2} modules cp -f %{SOURCE3} modules # Patch1: gnome-vfs-1.9.4.91-docdir.patch modifies doc/Makefile.am #%patch1 -p1 -b .docdir (cd modules && cp default-modules.conf default-modules.conf.with-menu-editing) ## clean out the methods that don't work with our setup DMC=modules/default-modules.conf.with-menu-editing perl -pi -e 's/all-applications:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/all-preferences:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/favorites:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/network:\s+libvfolder-desktop.so//g' $DMC ## these two should actually work ## perl -pi -e 's/applications-all-users:\s+libvfolder-desktop.so//g' $DMC ## perl -pi -e 's/preferences-all-users:\s+libvfolder-desktop.so//g' $DMC ## these are now in the vfolder-hacks patch #%patch2 -p1 -b .moved-menu-files #%patch3 -p0 -b .onlyshowin %patch5 -p1 -b .moved-menu-files %patch6 -p1 -b .only-show-in %patch7 -p1 -b .modules-conf %patch8 -p1 -b .newstat %patch9 -p1 -b .read-only %patch10 -p1 -b .old-modules %patch11 -p1 -b .network-uri %patch12 -p1 -b .never-show-if-empty %patch13 -p1 -b .hide-with-empty-subfolders %patch14 -p1 -b .no-private-methods %patch15 -p0 -b .vfolder-hacks %patch16 -p1 -b .attr %build # needed for patch10 (changing makefile to old vfolder backend) automake-1.4 # needed for patch16 (changing configure.in for EA) autoconf if pkg-config openssl ; then CPPFLAGS=`pkg-config --cflags openssl`; export CPPFLAGS LDFLAGS=`pkg-config --libs-only-L openssl`; export LDFLAGS fi %configure export tagname=CC make LIBTOOL=/usr/bin/libtool %install rm -fr %{buildroot} export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 export tagname=CC %makeinstall LIBTOOL=/usr/bin/libtool unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL rm -f $RPM_BUILD_ROOT%{_libdir}/gnome-vfs-2.0/modules/lib*.a rm -f $RPM_BUILD_ROOT%{_libdir}/*.la rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default ## why, dear god, why? rm -f $RPM_BUILD_ROOT%{_datadir}/aclocal/gob2.m4 install -m 644 modules/default-modules.conf.with-menu-editing $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/ ## Remove this line and update file list to revert to ## no-menu-editing-by-default # (cd $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/; mv default-modules.conf default-modules.conf.without-menu-editing; mv default-modules.conf.with-menu-editing default-modules.conf) rm -f $RPM_BUILD_ROOT%{_libdir}/bonobo/monikers/*.{a,la} %find_lang %{po_package} %clean rm -fr %{buildroot} %post export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` SCHEMAS="system_http_proxy.schemas" for S in $SCHEMAS; do gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/$S > /dev/null done /sbin/ldconfig %postun -p /sbin/ldconfig %files -f %{po_package}.lang %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README %dir %{_sysconfdir}/gnome-vfs-2.0 %dir %{_sysconfdir}/gnome-vfs-2.0/modules #%dir %{_sysconfdir}/gnome-vfs-2.0/vfolders %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf.with-menu-editing ## we aren't really using the .vfolder-info config files, ## so installing them is a little misleading. ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default %{_bindir}/* %{_libdir}/*.so.* %{_libdir}/gnome-vfs-2.0/modules %dir %{_libdir}/gnome-vfs-2.0 %{_libdir}/bonobo %{_libdir}/vfs %{_sysconfdir}/gconf/schemas/* ## conflicts with gnome-vfs 1, ignore for now ## %{_datadir}/man/man5/* %files devel %defattr(-, root, root) %{_libdir}/lib*.a %{_libdir}/lib*.so %{_libdir}/pkgconfig/* %{_libdir}/gnome-vfs-2.0/include/*.h %{_includedir}/* %{_datadir}/gtk-doc %changelog * Wed Oct 15 2003 Alexander Larsson 2.4.1-1 - Update to 2.4.1, fixes bug #107130 * Tue Sep 9 2003 Alexander Larsson 2.4.0-1 - update to 2.4.0 * Tue Sep 2 2003 Alexander Larsson 2.3.90-1 - update to 2.3.90 * Mon Aug 25 2003 Alexander Larsson 2.3.8-1 - update to 2.3.8 * Mon Aug 11 2003 Alexander Larsson 2.3.7-1 - update for gnome 2.3 * Tue Jul 22 2003 Nalin Dahyabhai 2.2.5-3 - rebuild, setting tagname to CC * Tue Jul 8 2003 Alexander Larsson 2.2.5-2.E - Rebuild * Wed Jun 04 2003 Elliot Lee - rebuilt * Tue May 27 2003 Alexander Larsson 2.2.5-1 - Update to 2.2.5 * Mon Mar 31 2003 Alexander Larsson 2.2.4-1 - Update to 2.2.4 * Mon Feb 24 2003 Elliot Lee - debuginfo rebuild * Mon Feb 24 2003 Alexander Larsson 2.2.2-3 - Added patch to fix smb crash (#84982) * Mon Feb 24 2003 Alexander Larsson 2.2.2-2 - Add patch to fix notify race (#84668) * Wed Feb 12 2003 Alexander Larsson 2.2.2-1 - 2.2.2, fixes bad memleak (#83791) * Tue Feb 11 2003 Havoc Pennington 2.2.1-3 - kill menu editing again, it was very very broken * Mon Feb 10 2003 Bill Nottingham 2.2.1-2 - fix file list (#68226) - prereq GConf2 * Mon Feb 10 2003 Alexander Larsson 2.2.1-1 - Update to 2.2.1. fixes gnome-theme-manager hang * Thu Feb 6 2003 Havoc Pennington 2.2.0-7 - move to menu editing modules.conf by default, we'll see if it works * Tue Jan 28 2003 Matt Wilson 2.2.0-6 - use LIBTOOL=/usr/bin/libtool * Mon Jan 27 2003 Havoc Pennington - it would help to *install* the stupid menu edit conf file - update the vfolder-hacks patch with some fixes * Fri Jan 24 2003 Havoc Pennington - hack up editable vfolder backend to maybe work (still not the default config file) * Wed Jan 22 2003 Havoc Pennington - include a non-default config file to use new vfolder method - build the new vfolder method * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 21 2003 Alexander Larsson - Update to 2.2.0 * Mon Jan 13 2003 Havoc Pennington - variation on the subfolders hack to try to fix it * Sat Jan 11 2003 Havoc Pennington - fix bug where empty folders with empty subfolders would still be visible. * Sat Jan 11 2003 Havoc Pennington - finish adapting desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - adapt desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - hardcode , it's stupid to ever override this. * Sat Jan 11 2003 Havoc Pennington - make network:/// use libdesktop.so, and modify libdesktop.so to support it * Sat Jan 11 2003 Havoc Pennington - Revert to George's vfolder backend from gnome-vfs-2.0.2 or so - put back libdesktop.so - don't build the new vfolder backend * Wed Jan 8 2003 Alexander Larsson 2.1.6-2 - Removed __libdir fix that was fixed upstream * Wed Jan 8 2003 Alexander Larsson 2.1.6-1 - Update to 2.1.6 * Tue Jan 7 2003 Nalin Dahyabhai 2.1.5-3 - rebuild * Mon Dec 16 2002 Tim Powers 2.1.5-2 - rebuild * Mon Dec 16 2002 Alexander Larsson 2.1.5-1 - Update to 2.1.5 * Thu Dec 12 2002 Nalin Dahyabhai - use OpenSSL's pkg-config information, if available * Wed Dec 4 2002 Havoc Pennington - 2.1.3.1 * Sun Nov 10 2002 Havoc Pennington - 2.1.3 - update moved-menu-files patch * Wed Oct 23 2002 Havoc Pennington - add patch for OnlyShowIn support - use plain menu files for .vfolder-info-default - don't install unused vfolder-info files * Tue Oct 8 2002 Havoc Pennington - require new gnome-mime-data in proper libdir - 2.0.4 - drop most patches as they are now upstream or don't apply to new vfolder code * Fri Aug 30 2002 Owen Taylor - Backport a gnome-vfs locking fix from CVS (Hopefully fixes #71419) * Fri Aug 23 2002 Havoc Pennington - make vfolder method read-only #72208 * Mon Aug 19 2002 Jonathan Blandford - notice when new files are installed * Tue Aug 13 2002 Havoc Pennington - don't include pointless .a files * Fri Aug 2 2002 Havoc Pennington - 2.0.2 - use vfolders for system-settings and server-settings * Tue Jul 16 2002 Havoc Pennington - fix OnlyShowIn * Tue Jun 25 2002 Owen Taylor - Version 2.0.1, fix missing po files * Sun Jun 16 2002 Havoc Pennington - 2.0.0 - put schema files in file list, and install them - put libdir/vfs in file list * Tue Jun 11 2002 Havoc Pennington - rebuild in different environment * Tue Jun 11 2002 Havoc Pennington - look for menus in redhat-menus * Fri Jun 07 2002 Havoc Pennington - rebuild in different environment * Wed Jun 5 2002 Havoc Pennington - 1.9.16 * Sun May 26 2002 Tim Powers - automated rebuild * Mon May 20 2002 Havoc Pennington - rebuild in different environment * Mon May 20 2002 Havoc Pennington - 1.9.15 - comment out docdir patch for now * Fri May 3 2002 Havoc Pennington - 1.9.14 * Thu Apr 4 2002 Jeremy Katz - 1.9.11 - update file list * Thu Feb 14 2002 Havoc Pennington - 1.9.7 * Thu Jan 31 2002 Owen Taylor - Fix location of installed docs not to conflict with gnome-vfs1 * Wed Jan 30 2002 Owen Taylor - Rebuild with new libs * Wed Jan 09 2002 Tim Powers - automated rebuild * Thu Jan 3 2002 Havoc Pennington - 1.0.4.91 snap * Mon Nov 26 2001 Havoc Pennington - 1.9.4.90 snap - require gnome-mime-data * Sun Oct 28 2001 Havoc Pennington - new snap, rebuild for glib 1.3.10 * Fri Oct 5 2001 Havoc Pennington - cvs snap * Fri Sep 21 2001 Havoc Pennington - rebuild cvs snap with changes merged upstream - fix a requires - fix up requires/buildrequires a bit * Tue Sep 18 2001 Havoc Pennington - initial gnome-vfs2 build, remove all patches - change config files not to be noreplace * Mon Aug 27 2001 Havoc Pennington - Add po files from sources.redhat.com * Mon Aug 20 2001 Havoc Pennington - fix #51864 (Gimp can't handle file: URIs) * Mon Aug 20 2001 Alexander Larsson 1.0.1-15 - Moved gnome-conf and pkgconfig files to the devel package - Fixes SHOULD-FIX bug #49795 * Mon Aug 6 2001 Alexander Larsson 1.0.1-14 - Added a patch that fixed AbiWord mimetype handling. * Fri Jul 27 2001 Jonathan Blandford - Add .desktop file sniffing * Tue Jul 24 2001 Havoc Pennington - don't do the giant trash scan thing; did not play nice with NFS. * Tue Jul 24 2001 Havoc Pennington - fix desktop-file.conf file * Tue Jul 24 2001 Havoc Pennington - change some URI scheme names * Fri Jul 20 2001 Alexander Larsson - Add pkgconfig and gnome-libs-devel build reqs. - Remove dependency on gnome-vfs-devel by doing some - CPPFLAGS and LDFLAGS magic * Wed Jul 11 2001 Havoc Pennington - add missing directories * Tue Jul 10 2001 Havoc Pennington - fix a segv - change which dirs the desktop VFS module points to * Sun Jul 08 2001 Havoc Pennington - add desktop VFS module hack * Fri Jul 6 2001 Trond Eivind Glomsrød - Remove Distribution and Vendor - Make the config files noreplace - Move .so links to devel subpackage - langify - Add BuildRequires - Don't mess with /etc/ld.so.conf - Use %%{_tmppath} - s/Copyright/License/ * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild. * Wed May 9 2001 Jonathan Blandford - New Version. * Tue Apr 17 2001 Jonathan Blandford - New Version. - clean up spec file some. * Mon Feb 19 2001 Gregory Leblanc - fix paths and macros * Tue Feb 22 2000 Ross Golder - Integrate into source tree --=-uazmxkOo5iyZC9kUE0ez-- From awilliam@whitemice.org Sun Jan 4 08:13:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mail.gnome.org (Postfix) with ESMTP id 7965F183D4; Sun, 4 Jan 2004 08:13:09 -0500 (EST) Received: from adsl-68-72-14-103.dsl.klmzmi.ameritech.net ([68.72.14.103] helo=estate1.whitemice.org) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ad840-0004TY-00; Sun, 04 Jan 2004 05:13:04 -0800 Received: from estate2.whitemice.org (estate2.whitemice.org [192.168.3.245]) by estate1.whitemice.org (8.12.5/8.12.5) with ESMTP id i04DGaAC007033; Sun, 4 Jan 2004 08:16:36 -0500 Subject: Re: Suggestion for file type detection approach From: Adam Williams To: Yves Dionne Cc: gnome-vfs-list@gnome.org, nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain Message-Id: <1073221987.5722.64.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 08:13:07 -0500 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. Yes, please! I mentioned EA awhile ago to no response; sniff, look at extensions, whatever - and keep your results. Even better if applications that created files put the EA tags in themselves. This is so obviously the right solution - Mac OS has been doing this forever, and Winblows is starting to make real use of EA as well. EA follow the file when copied, moved, etc... You could even store a thumbnail in EA and not generate one every time or cache it somewhere annoying like ".nautilus". > It works only for local files. Not sure this is true. The EA on NTFS can be accessed by CIFS calls, and NFSv4 at least supports extended attributes. But maybe niether are ture on Linux at this point. > If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. Works with ext3, XFS, and JFS (at least). > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. Excellent. From dobey@free.fr Sun Jan 4 12:19:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id 1926718685 for ; Sun, 4 Jan 2004 12:19:14 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdBtq-0007Aa-0W; Sun, 04 Jan 2004 12:18:50 -0500 Subject: Re: FUD about security and file extensions (was Re: Why file content sniffing sucks) From: Rodney Dawes To: "Jason A. Pfeil" Cc: Charles Goodwin , Fabio Gomes , Colin Walters , gnome-vfs-list@gnome.org In-Reply-To: References: <1072278440.1486.125.camel@hermes.intra.gs2.com.br> <20031224154241.GK1205@lazarus> <1072281561.4971.11.camel@firebrand> <1072283138.1087.26.camel@discomachinegun.prettypeople.org> <1072291008.15811.3.camel@nexus.verbum.private> <1072401563.945.33.camel@hermes.intra.gs2.com.br> <1072403078.27575.20.camel@mightymax.charlietech.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1073236729.26544.144.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:18:49 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On H=C3=ABn , 2003-12-29 at 10:21, Jason A. Pfeil wrote: > On Fri, 26 Dec 2003, Charles Goodwin wrote: > [...snip...] > > Yes, file sniffing is slow. So implement it in a way that does not > > affect the user. Last time I used Nautilus, I could scroll up and down > > and jump between folders without extra pause, whilst Nautilus updates > > itself in the background. So what is the issue? It only updates what > > is in immediate view (as I recall) so you just scroll to your desired > > file and, if necessary, wait the 2s for it to be detected. >=20 > I think that this is how it was supposed to be implemented, but I don't > believe that this implementation has actually been done. As a quick test= , > open /usr/bin in nautilus. On the box I am using to write this, /usr/bin > has 2,124 files in it. Nautilus took about 10 seconds to load the > contents of that directory. In comparison, use a shell and cd to /usr/bi= n. > Then, type the command: >=20 > echo * >=20 > and see how much faster that returns. echo * returned instantly on my bo= x. > If you want, you can do the echo * method first just so you can convince > yourself that nautilus is not caching things for the shell. And how do I convince myself that echo is doing all of the same activities that nautilus is? Doing a simple "echo *" has substantially less traffic to the X server. It doesn't tell you mime types, modification times, number of files in the child directories, or anything extra about the files. Hell, it doesn't even put the filenames on new lines. If you want to make a comparison like this for mime types, then either compare file and test-mime from the gnome-vfs tests/ directory, on a terminal, while redirecting STDIN and STDOUT to /dev/null, so that terminal X traffic and rendering speed doesn't come in to play. Then you should see that it is not the mime type detection that is slow. The gnome-vfs mime test and file take about the same time to complete. It took less than half a second for gnome-vfs to get the mime types of over 619 files on my system. > Also, when nautilus is opening the directory, take note of the extreme di= sk > churning you hear and note its absence when using the echo * command. FY= I, > the hardware I ran this on is a 1.8GHz P4 with 1GB RAM and U160 SCSI disk > on an Adaptec 7892A controller. Hardly pokey by any standards. Yes. The "echo *" command doesn't open any files at all. It's all done in the command line shell. It simply expands * to all filenames in the current directory, and spits them out on STDOUT. It is not doing anything complex at all. Maybe you should fix The GIMP to use "echo *" when it starts up. It takes a long time to load all those plug-ins. > If we want the average user to use Linux over Windows, we have to have a > system that is competitive not only in security, but also in speed. Whil= e > nautilus has improved greatly over the years, it is still *far* behind > explorer in speed and this file-type identification issue is a prime reas= on. s/Linux/GNOME/ Linux in general is as fast as, if not faster than, Windows. Nautilus is also just as fast as Explorer. Saying X is faster than Y because Y is doing more is ignorant. If Nautilus is slower than Explorer for you, it is a configuration issue, not an issue of how it detects the mime types. You really should spend your time profiling the GNOME libraries and Nautilus if you think your statement is true. Stating your opinion of what is wrong with it won't get it fixed. Proving where the speed bottlenecks are with profiling data and real comparisons with more constants than the hardware it was run on, will be much more useful. > > If Nautilus is wrongly detecting a file type it is a _bug_ and should b= e > > dealt with as such. It is nothing to do with the system used by > > Nautilus. Detection of type by file extension is far more error prone > > and relies much more on correctness of user input which is an > > unreasonable expection on lay users. >=20 > I dispute this notion. Proper training of users (not unreasonable) with = the > help of applications automatically setting file-types will go a long way > towards having good input from users. You can't claim a dispute and then agree. Reasonable training and application assistance will go a long way, yes. However, we shouldn't be relying on user-training. We should be writing applications that help the user to learn on their own. Psychology is a very important aspect to usability. Having a user do something on their own instills pride. Don't you feel like doing more when you do something yourself, as opposed to having to spend $1200 to learn to write a basic web page? Our applications should be smart enough to let the users know what they are doing, and if what they are doing is correct. Also, people migrating from Windows or Mac OS have a bit of training. They generally know enough about icon/label->action associations and similar, that they can figure out things fairly quickly. > [...snip...] > > > The bugs present in Micros~1 Windows are not due to file type detecti= on > > > by suffix.=20 > >=20 > > Wrong, they are. By due nature of the ridiculous method, people > > associate .jpg files or .gif files as images. This introduces a proble= m > > with visual association. > > Somebody gets an email with an attachment such as 'pretty.jpg.exe' or > > 'sexy.gif.pl' and they open it up. Yes, this is due to file type > > detection by suffix because you are subconciously causing people to > > recognise file types by file suffix and hence they can be easily > > mislead. > However, in this type of example, the extensions for both of these files > are .exe and .pl, respectively. Therefore there is no ambiguity since a > file ending in .exe is not a file ending in .jpg and a file ending in .pl > is not a file ending in .gif. The only time that this can cause a proble= m > is when the system *hides* the extension like Windows does. This is a > badly contrived example. No. It goes beyond hiding the extension. Many versions of the file system also only support a maximum of one period in the filename. This really causes problems. The suffix detection also plays a major role, but it is not the only contributing factor. > [...snip...] > >=20 > > One goal of Gnome is to make Free Software desktops a global reality (a= s > > if it already isn't). Introducing notions that add to the confusion > > just to save a few cpu cycles and/or to make things look snappier > > on-the-surface is no way to achieve that goal; unless you want a buggy, > > insecure system but that niche is already well filled. >=20 > Or unless you want to have widespread use. Unfortunately, the average us= er > expects a computer to be fast. By coupling the file extension method wit= h > a type-match check method when the file is opened using nautilus, you get > the best of both worlds. I fail to see the objection. It's just as fast > as the way Windows does it, and it's just as secure as the current way > that nautilus does it. Contriving a conflict is counter-productive. We do have widespread use. Not as widespread as, say, Windows, but still, we have many a user. That user-base is only increasing, as well. The average user does not expect their computer to be as fast as you claim. The average user, uses Windows. Windows is by no means fast. Using both methods of file type detection will gain us nothing. In fact, we already do use both methods. The suffix checking is generally a fall-back method, though. Read the code. It's right there in plain sight. Contriving conflicts is indeed counter-productive. Please stop. :) > > I wish this pointless discussion would go away. It's clogging up my > > inbox. Really, there's some damn clever guys hacking Gnome and this >=20 > You can always unsubscribe to the list or request to get messages in a > digest. However, terminating a discussion because it bores you or is a > minor inconvenience to you is not the right approach. > [...snip...] It's not only an annoyance to him. These mails have been going to far more lists than they should have, if any at all. Continuing a thread simply so that it does go on, is also not the right approach. -- dobey From dobey@free.fr Sun Jan 4 12:47:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id AFA641853E for ; Sun, 4 Jan 2004 12:47:52 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdCLf-0007BI-Ij; Sun, 04 Jan 2004 12:47:35 -0500 Subject: Re: Suggestion for file type detection approach From: Rodney Dawes To: ejk@ucsc.edu Cc: gnome-vfs-list@gnome.org In-Reply-To: <1073083582.3530.77.camel@whipple> References: <1073083582.3530.77.camel@whipple> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1073238454.26541.173.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:47:35 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > >Given the performance bottleneck imposed by sniffing, I suggest that it > >is not used anymore in directory listing routines. It should be used > >when the user tries to open an unknown file. Let's imagine this case: > > I don't think this is a good way of thinking about things. The questions are: > 1. Is sniffing a good idea? > 2. If so does it work correctly? > 3. If (1) and (2), is it performing fast enough? > > I think others have argued persuasively that sniffing is a good idea > since unix doesn't generally give file name suffixes to files (even > though gnome does), and often files have incorrect suffixes. > > A number of people have said that there are instances where sniffing is > not correctly determining the file type. If true, this is an excellent > argument for fixing those cases, but not at all an argument for throwing > away sniffing altogether. I've only seen one person say that. And as I understand, no real information was provided. Only a comment of "it broke on this one file." But yes, it is a good argument for improving the system, not removing the core functionality. > >From your benchmarking it is clear that (3) is a problem, and sniffing > is taking too long. This is not an argument for getting rid of it > though, just an argument for speeding it up. Someone suggested running > it through a profiler, but I doubt that will be worthwhile--the problem > is almost certainly the multiple disk accesses (your disk is having to > seek for each file). As others have pointed out, a two pass technique. > based on extension and then sniffing is also a bad idea since icons, etc > would change in the case of a discrepancy. It is not clear that 3 is a problem. It is only probable that 3 may be an issue on a certain machine with a certain configuration. I guarantee that the sniffing is not the bottleneck. Running it through a profiler will be much more worthwhile than sending mail to a list saying "it's slow." And yes, I am the one that suggested profiling. The disk i/o is most certainly not the bottleneck. Given the speed of hard disks today, seek time is not an issue. Even if it took the 12ms maximum seek time on a newer model hard disk, and you were loading a directory with 1000 files in it, that is only 12 seconds. Given the size of cache on newer hard disks, and the fact that people generally open up the same few folders, rather than opening / and traversing the tree looking for things, or opening odd folders randomly, I would guess that the maximum seek time would be around 3-4 milliseconds. It is much more likely some other problem that is specific to something Nautilus is doing to display the list of files. I also suggested other things than profiling, such as writing specific benchmarks to compare test-mime from gnome-vfs and file, which would be much more useful than saying "Nautilus must be slow because echo * is instantaneous" or other such nonsense. Real benchmarks are much more reliable than "it seemed slow" or "I used a stopwatch", as human error and perception can misinterpret how long it actually took to do something. > Sniffing is slow because it opens every file and reads some of it every > time you open a given directory. If you want to make this fast, cache > filetypes; now opening the huge mp3 folder is just a matter of reading a > single cache file and sniffing those files with a modification time > later than that of the cache file. Naturally this would only need to be > done for those really huge directories, it would probably be a waste for > directories with only a hundred files or fewer. Sniffing is not slow because it opens every file and reads some of it. Though, it may be if you end up opening network mounts, since all of the stat()s are network-bound, which is much slower than local hard disk access. There can surely be improvements in speed for network-bound i/o in gnome-vfs, and improvements in file type detection as well, since most all web server installations on the Internet, are broken. They also generally use filename extensions to determine what to send for the Content-Type: header. This is what gnome-vfs uses currently. > I don't think we need to worry about which approach is ultimately going > to perform faster. For a program like Nautilus either there is or is not > a human-noticeable lag time; improving performance when there is no lag > time is totally pointless. Aye. In general, the speed issues have nothing to do with the way the mime type is detected. Any claims that one is substantially faster than the other, is generally due to misperception. The real issues seem to generally be at a lower level, or totally unrelated, such as the issues with some of the thumbnailers. > A number of people have used Windows as an example of why we don't need > to sniff files; though there are a number of features in Windows worth > copying this is definitely not one of them. I have worked on some > commercial software and the number one frivolous bug report or unfixable > user issue occurs when the user attempts to open a file that has an > incorrect filename extension. People on this list have suggested that > this is a user problem not a software problem (i.e. that the user was > stupid and beyond help), but I can assure you that however obvious the > connection between the hidden Windows filename extension and the error > message that our program gave is to me and you, it was not obvious to a > large number of otherwise very intelligent people who just weren't as > knowledgeable about computers. People always think that the icon for a > file is somehow part of the file (it makes sense if you don't think > about it too hard), and so if a file has, say, a jpeg icon it doesn't > occur to them that it is not a jpeg. Indeed. -- dobey From david@davemalcolm.demon.co.uk Sun Jan 4 19:21:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by mail.gnome.org (Postfix) with ESMTP id 89DF618497; Sun, 4 Jan 2004 19:21:39 -0500 (EST) Received: from davemalcolm.demon.co.uk ([80.177.172.172] helo=[192.168.0.3]) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1AdIV0-000C9Z-0Y; Mon, 05 Jan 2004 00:21:38 +0000 Subject: Re: Suggestion for file type detection approach From: Dave Malcolm To: Yves Dionne Cc: Gnome VFS List , Nautilus List , gnome-list@gnome.org, "gnome-devel-list@gnome.org" In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1073262381.32307.3969.camel@shirehorse1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Jan 2004 00:26:22 +0000 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sat, 2004-01-03 at 00:57, Yves Dionne wrote: > On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > > > Why not support recording the mime-type of a file as meta-data (EA) on > > > filesystems that support it (every one of them at this point?). It > > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > > to clearly be the right way to do it. If GNOME VFS supported it then > > > it seems it would be easy to implement for alot of applications. > > > > > > > I agree with you, but while we must provide a quick solution, EA (and > > the attributes themselves) must be standardized cross-unix and > > cross-desktop. This will take some time to mature, since the mechanisms > > for sending files through the Internet (between computers, in general) > > must mature to support EA. I never used Apple operating systems, but it > > looks like they have such a mechanism. Nothing that a tar with EA > > support could not do. > > > > GNOME must provide room today to support state-of-the-art technologies > > in the future, but must at the same time provide solutions to today's > > users using today's technologies. > > > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > > > Indeed, but it's all we have for now. Now = 2.6. > > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". I think this is a great idea - in particular it gives users something they can adjust if the sniffing gets it wrong. If EAs aren't available, perhaps such "sniff overrides" could be stored using the Nautilus metadata system? Though that would make things even slower. > > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. > > It works only for local files. If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. > > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. From bugtraq@gs2.com.br Mon Jan 5 07:27:19 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from zeus.intra.gs2.com.br (unknown [200.165.137.90]) by mail.gnome.org (Postfix) with ESMTP id 3759218667 for ; Mon, 5 Jan 2004 07:27:17 -0500 (EST) Received: from hermes.intra.gs2.com.br (hermes.intra.gs2.com.br [192.168.1.1]) by zeus.intra.gs2.com.br (Postfix) with ESMTP id 245F0302D1; Mon, 5 Jan 2004 09:33:37 -0300 (BRT) Subject: Re: Suggestion for file type detection approach From: Fabio Gomes To: Rodney Dawes Cc: ejk@ucsc.edu, gnome-vfs-list@gnome.org In-Reply-To: <1073238454.26541.173.camel@blackbox.boston.ximian.com> References: <1073083582.3530.77.camel@whipple> <1073238454.26541.173.camel@blackbox.boston.ximian.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1073305961.1035.25.camel@hermes.intra.gs2.com.br> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 09:32:42 -0300 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Em Dom, 2004-01-04 às 14:47, Rodney Dawes escreveu: > On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > > >Given the performance bottleneck imposed by sniffing, I suggest that it > > >is not used anymore in directory listing routines. It should be used > > >when the user tries to open an unknown file. Let's imagine this case: > > > > I don't think this is a good way of thinking about things. The questions are: > > 1. Is sniffing a good idea? > > 2. If so does it work correctly? > > 3. If (1) and (2), is it performing fast enough? > > > > I think others have argued persuasively that sniffing is a good idea > > since unix doesn't generally give file name suffixes to files (even > > though gnome does), and often files have incorrect suffixes. > > > > A number of people have said that there are instances where sniffing is > > not correctly determining the file type. If true, this is an excellent > > argument for fixing those cases, but not at all an argument for throwing > > away sniffing altogether. > > I've only seen one person say that. And as I understand, no real > information was provided. Only a comment of "it broke on this one file." > But yes, it is a good argument for improving the system, not removing > the core functionality. > > > >From your benchmarking it is clear that (3) is a problem, and sniffing > > is taking too long. This is not an argument for getting rid of it > > though, just an argument for speeding it up. Someone suggested running > > it through a profiler, but I doubt that will be worthwhile--the problem > > is almost certainly the multiple disk accesses (your disk is having to > > seek for each file). As others have pointed out, a two pass technique. > > based on extension and then sniffing is also a bad idea since icons, etc > > would change in the case of a discrepancy. > > It is not clear that 3 is a problem. It is only probable that 3 may be > an issue on a certain machine with a certain configuration. I guarantee > that the sniffing is not the bottleneck. Running it through a profiler > will be much more worthwhile than sending mail to a list saying "it's > slow." And yes, I am the one that suggested profiling. The disk i/o is > most certainly not the bottleneck. Given the speed of hard disks today, > seek time is not an issue. Even if it took the 12ms maximum seek time on > a newer model hard disk, and you were loading a directory with 1000 > files in it, that is only 12 seconds. Given the size of cache on newer > hard disks, and the fact that people generally open up the same few > folders, rather than opening / and traversing the tree looking for > things, or opening odd folders randomly, I would guess that the maximum > seek time would be around 3-4 milliseconds. It is much more likely some > other problem that is specific to something Nautilus is doing to display > the list of files. I also suggested other things than profiling, such > as writing specific benchmarks to compare test-mime from gnome-vfs and > file, which would be much more useful than saying "Nautilus must be slow > because echo * is instantaneous" or other such nonsense. Real benchmarks > are much more reliable than "it seemed slow" or "I used a stopwatch", as > human error and perception can misinterpret how long it actually took to > do something. "ONLY" 12 seconds? Is that acceptable for a directory with 1000 files? Can a human error of perception misinterpret the distance between <1s and 20s multiple times with the help of a stopwatch? You must be kidding. :-P > Aye. In general, the speed issues have nothing to do with the way the > mime type is detected. Any claims that one is substantially faster than > the other, is generally due to misperception. The real issues seem to > generally be at a lower level, or totally unrelated, such as the issues > with some of the thumbnailers. Test it by yourself: http://mail.gnome.org/archives/gnome-devel-list/2004-January/msg00010.html If your results confirm my "misperception", I'll blindly agree with everything that you say. :-) I'm not advocating the removal of functionality. People have already pointed how to fix the performance and misidentification issues in efficient manners. What I am trying to do is show the non-believers where the performance problem actually is. Best regards, -- Fabio Gomes de Souza (+55 81 9127-0597) .- GS2 TECNOLOGIA DA INFORMACAO LTDA :: www.gs2.com.br |- IT Infrastructure :: Security :: Embedded systems :: Linux `- Olinda, Brazil - +55 81 3492-7777 - negocios@gs2.com.br From gkarabin@pobox.com Sat Jan 17 20:36:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id B3AD81820C; Sat, 17 Jan 2004 20:36:20 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0I1aHqG013829; Sat, 17 Jan 2004 17:36:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: federico@gnu.org From: George Karabin Subject: tiff multi-document files Date: Sat, 17 Jan 2004 17:36:16 -0800 To: eog-list@gnome.org, gnome-vfs-list@gnome.org X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Scanning and fax applications sometimes store multiple images in a single image/tiff file. I'd like to modify eog to display multi-image tiff files as a flat collection of files, as if it were a directory. Right now it's ignoring the other images in the file. I want to add a gnome-vfs module to map libtiff's directory feature to a gnome-vfs URI with archive-file-format-like methods. For each image file it opens, eog would test to see if it's image/tiff, and then try to open the directory. If the module's installed, then it'll get a directory handle and create the collection. Does the idea sound OK in principle for eog? I'm not sure how much eog wants to know about file-format-specific stuff like this, so I'm asking up-front. I don't think it makes sense to handle these sorts of files in gdk - this doesn't really map well to the animation interface, and there wouldn't be enough developers using it to justify changing APIs. So if this is done, eog has to learn about this tiff idiosyncrasy. Likewise, does this sound OK for gnome-vfs? I think there's less controversy here, but this is a fairly obscure use case. I can't imagine too many apps actually caring to use this, so I hope it's not considered bloat and a bad dependency. - George From jens@triq.net Sun Jan 18 05:19:55 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail4.ewetel.de (mail4-141.ewetel.de [212.6.122.141]) by mail.gnome.org (Postfix) with ESMTP id 4208118212; Sun, 18 Jan 2004 05:19:55 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-74-180.ewetel.net [80.228.74.180]) by mail4.ewetel.de (8.12.1/8.12.9) with ESMTP id i0IAJqHB026433; Sun, 18 Jan 2004 11:19:53 +0100 (MET) Date: Sun, 18 Jan 2004 11:34:27 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org Subject: Re: tiff multi-document files In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi George, On Sat, 17 Jan 2004, George Karabin wrote: > I want to add a gnome-vfs module to map libtiff's directory feature to > a gnome-vfs URI with archive-file-format-like methods. For each image > file it opens, eog would test to see if it's image/tiff, and then try > to open the directory. If the module's installed, then it'll get a > directory handle and create the collection. Nice. > Does the idea sound OK in principle for eog? I'm not sure how much eog > wants to know about file-format-specific stuff like this, so I'm asking > up-front. I don't think it makes sense to handle these sorts of files > in gdk - this doesn't really map well to the animation interface, and > there wouldn't be enough developers using it to justify changing APIs. > So if this is done, eog has to learn about this tiff idiosyncrasy. > > Likewise, does this sound OK for gnome-vfs? I think there's less > controversy here, but this is a fairly obscure use case. I can't > imagine too many apps actually caring to use this, so I hope it's not > considered bloat and a bad dependency. Actually, I think it should be possible to write a gnome-vfs module, which adds a new URI scheme and handles such tiff files properly. If it behaves like a directory from the gnome-vfs client point of view, eog will automatically use the collection view for this then. I am not very familar with 3rd party gnome-vfs modules, but AFAICS you neither need to touch gnome-vfs nor eog to get this working. Regards, Jens From alexl@redhat.com Mon Jan 19 04:39:29 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 2721E180EB; Mon, 19 Jan 2004 04:39:29 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNl31117; Mon, 19 Jan 2004 04:39:23 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNa09346; Mon, 19 Jan 2004 04:39:23 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0J9d1cG019229; Mon, 19 Jan 2004 04:39:02 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: Jens Finke Cc: George Karabin , eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 19 Jan 2004 10:39:21 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > > Does the idea sound OK in principle for eog? I'm not sure how much eog > > wants to know about file-format-specific stuff like this, so I'm asking > > up-front. I don't think it makes sense to handle these sorts of files > > in gdk - this doesn't really map well to the animation interface, and > > there wouldn't be enough developers using it to justify changing APIs. > > So if this is done, eog has to learn about this tiff idiosyncrasy. > > > > Likewise, does this sound OK for gnome-vfs? I think there's less > > controversy here, but this is a fairly obscure use case. I can't > > imagine too many apps actually caring to use this, so I hope it's not > > considered bloat and a bad dependency. > > Actually, I think it should be possible to write a gnome-vfs module, which > adds a new URI scheme and handles such tiff files properly. If it behaves > like a directory from the gnome-vfs client point of view, eog will > automatically use the collection view for this then. This is called "chained uris", and gnome-vfs has some code for it. However, at the moment it just doesn't work. My hope is that eventually we'll get it fixed though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded vegetarian card sharp with a robot buddy named Sparky. She's a mistrustful paranoid cab driver with her own daytime radio talk show. They fight crime! From gkarabin@pobox.com Mon Jan 19 16:49:06 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from util.ext.ti.com (util.ext.ti.com [192.91.75.135]) by mail.gnome.org (Postfix) with ESMTP id 15A5D180FE for ; Mon, 19 Jan 2004 16:49:06 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by util.ext.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn55O004430 for ; Mon, 19 Jan 2004 15:49:05 -0600 (CST) Received: from sdca.asp.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn4rj024363 for ; Mon, 19 Jan 2004 15:49:04 -0600 (CST) Received: from [146.252.133.9] (HELO pobox.com) by sdca.asp.ti.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 3657067 for gnome-vfs-list@gnome.org; Mon, 19 Jan 2004 13:59:43 -0800 Message-ID: <400C50D0.3090701@pobox.com> Date: Mon, 19 Jan 2004 13:49:04 -0800 From: George J Karabin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gnome-vfs-list@gnome.org Subject: [patch] tar method won't open root directory of archive Content-Type: multipart/mixed; boundary="------------060702050303070000000102" Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------060702050303070000000102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I haven't seen any documentation in gnome-vfs to indicate how one should encode the root directory of an archive into a URI, but empirically, it looks like something like either "foo.tar#tar:" or "foo.tar#tar:/" should work (gnome-vfs expands the former to the latter before giving the uri to the module's method). The tar method doesn't handle either of these cases. The attached patch fixes this. Try out something like "gnomevfs-ls /path-to-file/foo.tar#:" before and after the patch as a test case. No CVS access for me - can someone apply it if it passes review? The problem's filed in bugzilla as well: http://bugzilla.gnome.org/show_bug.cgi?id=131959 - George --------------060702050303070000000102 Content-Type: text/plain; name="gnome-vfs-2.4.1-handle-root.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gnome-vfs-2.4.1-handle-root.patch" --- gnome-vfs-2.4.1/modules/tar-method.c.handle-root 2002-05-12 20:38:29.000000000 -0700 +++ gnome-vfs-2.4.1/modules/tar-method.c 2004-01-19 12:43:14.000000000 -0800 @@ -51,6 +51,7 @@ int current_index; gchar *filename; gboolean is_directory; + gboolean is_root; } FileHandle; #define TARPET_BLOCKSIZE (sizeof (union TARPET_block)) @@ -154,35 +155,42 @@ return ret; } -static GNode* -tree_lookup_entry (const GNode *tree, const gchar *name) +static gboolean +tree_lookup_entry (const GNode *tree, const gchar *name, GNode **node) { - GNode *ret; char *root = g_strdup (name); char *txt = root; - - if (txt[0] == '/') - txt++; - ret = real_lookup_entry (tree, txt, 1); - if (!ret && txt[strlen (txt) - 1] != '/') + if (txt[0] == '/') + { + if (txt[1] == '\0') + { + g_free (root); + return TRUE; + } + else + txt++; + } + + *node = real_lookup_entry (tree, txt, 1); + if (!*node && txt[strlen (txt) - 1] != '/') { txt = g_strconcat (txt, "/", NULL); g_free (root); root = txt; - ret = real_lookup_entry (tree, txt, 1); + *node = real_lookup_entry (tree, txt, 1); } g_free (root); - if (ret && ret != tree->children) + if (*node && *node != tree->children) { - union TARPET_block *b = ret->data; + union TARPET_block *b = (*node)->data; b--; if (b->p.typeflag == TARPET_TYPE_LONGFILEN) - ret = ret->next; + *node = (*node)->next; } - return ret; + return FALSE; } static TarFile* read_tar_file (GnomeVFSHandle *handle) @@ -228,7 +236,7 @@ } split_name (ret->blocks[i].p.name, &dir, &rest); - node = tree_lookup_entry (ret->info_tree, dir); + tree_lookup_entry (ret->info_tree, dir, &node); if (!node) { @@ -322,7 +330,7 @@ tar = ensure_tarfile (uri); if (!tar) return GNOME_VFS_ERROR_BAD_FILE; - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); if (!node) { tar_file_unref (tar); @@ -468,13 +476,17 @@ union TARPET_block *start, *current; GNode *node; int i; + gboolean is_root; if (!uri->parent) return GNOME_VFS_ERROR_INVALID_URI; tar = ensure_tarfile (uri); if (uri->text) { - node = tree_lookup_entry (tar->info_tree, uri->text); + is_root = tree_lookup_entry (tar->info_tree, uri->text, &node); + } + if (!is_root) + { if (!node) { tar_file_unref (tar); @@ -490,8 +502,11 @@ else current = NULL; } - else + if (is_root || !uri->text) { + /* FIXME: gnome-vfs never seems to generate !uri->text + condition. Is it permissible by contract? */ + node = tar->info_tree; if (!node) { @@ -516,6 +531,7 @@ break; new_handle->current_index = i; new_handle->is_directory = TRUE; + new_handle->is_root = is_root; *method_handle = (GnomeVFSMethodHandle*) new_handle; @@ -550,7 +566,7 @@ int i; if (uri->text) - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); else node = tar->info_tree->children; @@ -635,15 +651,16 @@ GnomeVFSURI *uri; gchar *str; GNode *node; - + gboolean is_root; + if (!handle->current) return GNOME_VFS_ERROR_EOF; str = g_strconcat (handle->filename, "#tar:", handle->current->p.name, NULL); uri = gnome_vfs_uri_new (str); do_get_file_info (method, uri, file_info, 0, context); - node = tree_lookup_entry (handle->tar->info_tree, uri->text); - if (!node) + is_root = tree_lookup_entry (handle->tar->info_tree, uri->text, &node); + if (!node && !is_root) { gnome_vfs_uri_unref (uri); return GNOME_VFS_ERROR_NOT_FOUND; --------------060702050303070000000102-- From cbhoh@yahoo.com Tue Jan 20 01:36:27 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60307.mail.yahoo.com (web60307.mail.yahoo.com [216.109.118.118]) by mail.gnome.org (Postfix) with SMTP id 58F7518675 for ; Tue, 20 Jan 2004 01:36:27 -0500 (EST) Message-ID: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Received: from [161.142.100.80] by web60307.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 22:36:27 PST Date: Mon, 19 Jan 2004 22:36:27 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: gnome_vfs_get_mime_type does NOT get the mime_type To: gnome-vfs-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi guys, I need some help here, today I just use jhbuild to rebuild the 2.5 gnome. I noticed that the gnome_vfs_get_mime_type or gnome_vfs_get_mime_type_from_uri does not work. since the latest yelp use the gnome-vfs to determine the correct mimetype and then respond to the help file according to mime-type. For whatever file I use gnome_vfs_get_mime_type to retrive, I keep getting application/octect-stream. Is there anything i miss out about ? HOH ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Tue Jan 20 02:17:30 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id 9E92818136; Tue, 20 Jan 2004 02:17:29 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0K7HPqG014225; Mon, 19 Jan 2004 23:17:25 -0800 (PST) In-Reply-To: <1074505161.2413.109.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Mon, 19 Jan 2004 23:17:26 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: >> Actually, I think it should be possible to write a gnome-vfs module, >> which >> adds a new URI scheme and handles such tiff files properly. If it >> behaves >> like a directory from the gnome-vfs client point of view, eog will >> automatically use the collection view for this then. > > This is called "chained uris", and gnome-vfs has some code for it. > However, at the moment it just doesn't work. My hope is that eventually > we'll get it fixed though. I looked at the archives for this list on chaining and the shared vfs ideas on xdg-list. Has anything come of your idea for a common VFS URI spec: https://listman.redhat.com/archives/xdg-list/2003-September/ msg00110.html ? Do you think it makes any sense to attempt to fix chaining before attempting such a spec? Regarding a VFS URI spec, I thought I'd go looking for relevant internet standards and drafts, and note them here. They might make for some good references for requirements gathering for anyone thinking about such a spec. Anyway, RFC 2396 provides a general BNF for URIs that seems workable[1]. RFC 2396bis was in the running to succeed it, but expired in December. It had expanded on encoding and escaping guidelines, which 2396 was really vague on, but basically left the specifics for URI components to TBD docs that describe those URIs. I.e., no conclusive help here anytime soon. I don't know why it lost momentum, and am not sure if there's any sense trying to salvage some of its ideas or not. Maybe it makes sense to get URIs that VFS projects care about into ietf drafts? Looks to be a slow-moving standards body - dunno if it's worth the effort or not - I don't have any experience with standards bodies. RFC 1738 provides rules for some specific URI types. RFC1738bis is an update based on 2396bis, so it's left hanging as well. The ssh URI draft that Jeff Waugh referred to some time back is based on other drafts that are based on the expired 2396bis, so it seems likely that it'll expire as well unless 239bis picks up again. Interesting RFCs: ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt ftp://ftp.rfc-editor.org/in-notes/rfc2079.txt ftp://ftp.rfc-editor.org/in-notes/rfc2483.txt ftp://ftp.rfc-editor.org/in-notes/rfc2168.txt Other relevant/interesting drafts: http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri- rfc2396bis-03.txt (expired) http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-06.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri -01.txt - George [1] It's old enough that for all I know gnome-vfs or kio could be based on it. I have no idea if that's the case or not. From alexl@redhat.com Tue Jan 20 03:00:52 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9DB8618958; Tue, 20 Jan 2004 03:00:52 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80ql14111; Tue, 20 Jan 2004 03:00:52 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80qa30628; Tue, 20 Jan 2004 03:00:52 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0K80UcG000940; Tue, 20 Jan 2004 03:00:31 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040120063627.8391.qmail@web60307.mail.yahoo.com> References: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074585650.2413.185.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 20 Jan 2004 09:00:51 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 07:36, Chee Bin HOH wrote: > Hi guys, > > I need some help here, today I just use jhbuild to > rebuild the 2.5 gnome. I noticed that the > gnome_vfs_get_mime_type or > gnome_vfs_get_mime_type_from_uri does not work. > > since the latest yelp use the gnome-vfs to determine > the correct mimetype and then respond to the help file > according to mime-type. > > For whatever file I use gnome_vfs_get_mime_type to > retrive, I keep getting application/octect-stream. > > Is there anything i miss out about ? Did you install shared-mime-info? Did you set XDG_DATA_DIRS to include $prefix/share? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a globe-trotting skateboarding hairdresser who dotes on his loving old ma. She's a foxy cat-loving barmaid with an incredible destiny. They fight crime! From cbhoh@yahoo.com Wed Jan 21 01:47:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60309.mail.yahoo.com (web60309.mail.yahoo.com [216.109.118.120]) by mail.gnome.org (Postfix) with SMTP id 59D2718254 for ; Wed, 21 Jan 2004 01:47:13 -0500 (EST) Message-ID: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Received: from [161.142.195.153] by web60309.mail.yahoo.com via HTTP; Tue, 20 Jan 2004 21:20:17 PST Date: Tue, 20 Jan 2004 21:20:17 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074585650.2413.185.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --- Alexander Larsson wrote: > Did you install shared-mime-info? Did you set > XDG_DATA_DIRS to include > $prefix/share? I did install share-mime-info from cvs.freedesktop.org (as requested by jhbuild), but I did not set the env XDG_DATA_DIRS. I need to set XDG_DATA_DIRS while I build share-mime-info or others? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a globe-trotting skateboarding hairdresser who > dotes on his loving old > ma. She's a foxy cat-loving barmaid with an > incredible destiny. They fight > crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From alexl@redhat.com Wed Jan 21 05:27:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9AF4B181E9; Wed, 21 Jan 2004 05:27:50 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARol29294; Wed, 21 Jan 2004 05:27:50 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARoa13682; Wed, 21 Jan 2004 05:27:50 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LARScG018691; Wed, 21 Jan 2004 05:27:28 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040121052017.24059.qmail@web60309.mail.yahoo.com> References: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074680868.2413.359.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:49 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > --- Alexander Larsson wrote: > > Did you install shared-mime-info? Did you set > > XDG_DATA_DIRS to include > > $prefix/share? > > I did install share-mime-info from cvs.freedesktop.org > (as requested by jhbuild), but I did not set the env > XDG_DATA_DIRS. > > I need to set XDG_DATA_DIRS while I build > share-mime-info or others? No, not while building. You need to set it when running apps. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a genetically engineered vegetarian inventor with a winning smile and a way with the ladies. She's a beautiful nymphomaniac research scientist on the trail of a serial killer. They fight crime! From alexl@redhat.com Wed Jan 21 05:27:13 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 37B74181E9; Wed, 21 Jan 2004 05:27:13 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBl29170; Wed, 21 Jan 2004 05:27:11 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBa13574; Wed, 21 Jan 2004 05:27:11 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LAQmcG018568; Wed, 21 Jan 2004 05:26:49 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org In-Reply-To: References: <1074505161.2413.109.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:09 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 08:17, George Karabin wrote: > On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > > > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > >> Actually, I think it should be possible to write a gnome-vfs module, > >> which > >> adds a new URI scheme and handles such tiff files properly. If it > >> behaves > >> like a directory from the gnome-vfs client point of view, eog will > >> automatically use the collection view for this then. > > > > This is called "chained uris", and gnome-vfs has some code for it. > > However, at the moment it just doesn't work. My hope is that eventually > > we'll get it fixed though. > > > I looked at the archives for this list on chaining and the shared vfs > ideas on xdg-list. Has anything come of your idea for a common VFS URI > spec: > https://listman.redhat.com/archives/xdg-list/2003-September/ > msg00110.html ? Do you think it makes any sense to attempt to fix > chaining before attempting such a spec? There hasn't been any work on it that I know of. And in such a spec it would be nice if chaining was supported. > Regarding a VFS URI spec, I thought I'd go looking for relevant > internet standards and drafts, and note them here. They might make for > some good references for requirements gathering for anyone thinking > about such a spec. In some sense its sort of unfortunate that gnome-vfs uris are based on normal URIs, because that limits us a bit and in some cases it causes trouble because people expect that gnome-vfs should support all sorts of things you can do with web-uris, such as mailto:, callto:, javascript: etc. In fact, we partially handle these by installing handler app settings for them, but in reality they are not really gnome-vfs uris. The way gnome-vfs currently handles chained uris is described in gnome-vfs/doc/uri.txt. Its working to some extent, but the work has never really been finalized and polished up to work in the desktop. To make it work you'd have to: * Work on the chained methods (zip, tar, gzip etc) to make them work better than they do today. The existance of the gnome-vfs daemon in 2.5 should make this easier * Finish the work with putting chained uri handlers into the mime info, so that the file manager can now what file types are chainable * Make the file handler recognize chainable file types and browse them * Make all users of gnome-vfs correctly handle chained uris (i.e. gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns file:///some/file.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an old-fashioned day-dreaming Green Beret possessed of the uncanny powers of an insect. She's a cold-hearted antique-collecting hooker married to the Mob. They fight crime! From cbhoh@yahoo.com Wed Jan 21 06:22:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60306.mail.yahoo.com (web60306.mail.yahoo.com [216.109.118.117]) by mail.gnome.org (Postfix) with SMTP id 9AC8718422 for ; Wed, 21 Jan 2004 06:22:51 -0500 (EST) Message-ID: <20040121112245.44069.qmail@web60306.mail.yahoo.com> Received: from [161.142.195.41] by web60306.mail.yahoo.com via HTTP; Wed, 21 Jan 2004 03:22:45 PST Date: Wed, 21 Jan 2004 03:22:45 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074680868.2413.359.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hey, it works. ;) Thank! --- Alexander Larsson wrote: > On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > > --- Alexander Larsson wrote: > > > Did you install shared-mime-info? Did you set > > > XDG_DATA_DIRS to include > > > $prefix/share? > > > > I did install share-mime-info from > cvs.freedesktop.org > > (as requested by jhbuild), but I did not set the > env > > XDG_DATA_DIRS. > > > > I need to set XDG_DATA_DIRS while I build > > share-mime-info or others? > > No, not while building. You need to set it when > running apps. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a genetically engineered vegetarian inventor > with a winning smile and a > way with the ladies. She's a beautiful nymphomaniac > research scientist on the > trail of a serial killer. They fight crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Sat Jan 24 00:53:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-03-eri0.socal.rr.com (ms-smtp-03-qfe0.socal.rr.com [66.75.162.135]) by mail.gnome.org (Postfix) with ESMTP id 73D0A182A2; Sat, 24 Jan 2004 00:53:14 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-03-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0O5rAF3022083; Fri, 23 Jan 2004 21:53:11 -0800 (PST) In-Reply-To: <1074680829.2413.357.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9618B740-4E31-11D8-B6FD-000A95A6935E@pobox.com> Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Fri, 23 Jan 2004 21:53:08 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 21, 2004, at 2:27 AM, Alexander Larsson wrote: > In some sense its sort of unfortunate that gnome-vfs uris are based on > normal URIs, because that limits us a bit and in some cases it causes > trouble because people expect that gnome-vfs should support all sorts > of > things you can do with web-uris, such as mailto:, callto:, javascript: > etc. In fact, we partially handle these by installing handler app > settings for them, but in reality they are not really gnome-vfs uris. Regarding the IETF docs, the thing I'm most interested in is to be sure that the grammar that they publish for URIs are the same as what gnome-vfs uses, so that URIs that are appropriate to the VFS can be generated from some external source, and be handled by a gnome-vfs client that doesn't necessarily know it's content. > The way gnome-vfs currently handles chained uris is described in > gnome-vfs/doc/uri.txt. Its working to some extent, but the work has > never really been finalized and polished up to work in the desktop. > Thanks - the text files aren't in the release tarballs. Looking at them in cvs helps out a lot. > To make it work you'd have to: > * Work on the chained methods (zip, tar, gzip etc) to make them work > better than they do today. The existance of the gnome-vfs daemon in 2.5 > should make this easier > * Finish the work with putting chained uri handlers into the mime info, > so that the file manager can now what file types are chainable > * Make the file handler recognize chainable file types and browse them > * Make all users of gnome-vfs correctly handle chained uris (i.e. > gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns > file:///some/file.) Thanks for the laundry list - I can start working toward these. I'll be away from email for a few days, but I'll be working my way through the new code over the course of the week. - George From thomas.cataldo@aliacom.fr Sun Jan 25 09:14:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0902.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 36753187E9 for ; Sun, 25 Jan 2004 09:14:21 -0500 (EST) Received: from localhost (AToulouse-206-1-16-219.w81-50.abo.wanadoo.fr [81.50.219.219]) by mwinf0902.wanadoo.fr (SMTP Server) with ESMTP id 8F0FD18000CC for ; Sun, 25 Jan 2004 15:14:19 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 0A33410712E for ; Sun, 25 Jan 2004 15:09:12 +0100 (CET) Subject: [PATCH] nntp method leak fixes From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-P0V5Zy6gc1b7U4iju1UH" Message-Id: <1075039751.12033.9.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 25 Jan 2004 15:09:12 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-P0V5Zy6gc1b7U4iju1UH Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Here is a patch to fix a few leaks in the nntp method. I tested it using gnomevfs-ls nntp:///alt.binaries.anime regards, Thomas. --=-P0V5Zy6gc1b7U4iju1UH Content-Disposition: attachment; filename=nntp-method-leaks.diff Content-Type: text/x-patch; name=nntp-method-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1715 diff -u -r1.1715 ChangeLog --- ChangeLog 23 Jan 2004 09:59:44 -0000 1.1715 +++ ChangeLog 25 Jan 2004 13:58:56 -0000 @@ -1,3 +1,8 @@ +2004-01-25 Thomas Cataldo + + * modules/nntp-method.c: (parse_date_string), (parse_header): some + memory leak fixes. + 2004-01-23 Alexander Larsson * schemas/Makefile.am: Index: modules/nntp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/nntp-method.c,v retrieving revision 1.5 diff -u -r1.5 nntp-method.c --- modules/nntp-method.c 16 Jun 2002 23:43:35 -0000 1.5 +++ modules/nntp-method.c 25 Jan 2004 13:58:57 -0000 @@ -814,6 +814,12 @@ g_message("error parsing %s, %s", date_string, temp_str); } + if (filename != NULL) { + g_free (filename); + } + if (linkname != NULL) { + g_free (linkname); + } g_free(temp_str); *t = s.st_mtime; @@ -904,6 +910,8 @@ file_start = strrchr (temp_str, '-'); if (file_start == NULL) { + g_free (*message_id); + g_free (temp_str); return FALSE; } --=-P0V5Zy6gc1b7U4iju1UH-- From cbhoh@mimos.my Wed Jan 28 05:45:42 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Jan 2004 18:39:13 +0800 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH From thomas.cataldo@aliacom.fr Thu Jan 29 21:06:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0904.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 32FD318B2C for ; Thu, 29 Jan 2004 21:06:53 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0904.wanadoo.fr (SMTP Server) with ESMTP id 951C0180012A for ; Fri, 30 Jan 2004 03:06:49 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 82288106FD4 for ; Fri, 30 Jan 2004 03:00:53 +0100 (CET) Subject: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-vEputk1gGiSFtfo2JnkO" Message-Id: <1075428053.15247.11.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 03:00:53 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-vEputk1gGiSFtfo2JnkO Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests agains ftp and http urls. By the way, as my previous patch against the nntp method was not reviewed, could you tell me if this list is the right place to send patches, or if a bug report is a better way. cheers, Thomas. --=-vEputk1gGiSFtfo2JnkO Content-Disposition: attachment; filename=vfs-socket-leaks.diff Content-Type: text/x-patch; name=vfs-socket-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1716 diff -u -r1.1716 ChangeLog --- ChangeLog 27 Jan 2004 18:59:08 -0000 1.1716 +++ ChangeLog 30 Jan 2004 01:55:40 -0000 @@ -1,3 +1,12 @@ +2004-01-30 Thomas Cataldo + + plug some gnome_vfs_socket leaks. + + * libgnomevfs/gnome-vfs-socket-buffer.c: + (gnome_vfs_socket_buffer_destroy): + * modules/ftp-method.c: (do_transfer_command), (end_transfer), + (ftp_connection_create), (ftp_connection_destroy): + 2004-01-27 David Hawthorne * daemon/gnome-vfs-daemon.c Index: libgnomevfs/gnome-vfs-socket-buffer.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/libgnomevfs/gnome-vfs-socket-buffer.c,v retrieving revision 1.8 diff -u -r1.8 gnome-vfs-socket-buffer.c --- libgnomevfs/gnome-vfs-socket-buffer.c 15 Jan 2004 09:55:51 -0000 1.8 +++ libgnomevfs/gnome-vfs-socket-buffer.c 30 Jan 2004 01:55:41 -0000 @@ -104,6 +104,7 @@ if (close_socket) { gnome_vfs_socket_close (socket_buffer->socket); + g_free(socket_buffer->socket); } g_free (socket_buffer); return GNOME_VFS_OK; Index: modules/ftp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/ftp-method.c,v retrieving revision 1.96 diff -u -r1.96 ftp-method.c --- modules/ftp-method.c 22 Jan 2004 12:29:10 -0000 1.96 +++ modules/ftp-method.c 30 Jan 2004 01:55:44 -0000 @@ -62,14 +62,12 @@ typedef struct { GnomeVFSMethodHandle method_handle; - GnomeVFSInetConnection *inet_connection; GnomeVFSSocketBuffer *socket_buf; GnomeVFSURI *uri; gchar *cwd; GString *response_buffer; gchar *response_message; gint response_code; - GnomeVFSInetConnection *data_connection; GnomeVFSSocketBuffer *data_socketbuf; GnomeVFSFileOffset offset; enum { @@ -384,6 +382,7 @@ char *host = NULL; gint port; GnomeVFSResult result; + GnomeVFSInetConnection *data_connection; GnomeVFSSocket *socket; /* Image mode (binary to the uninitiated) */ @@ -414,7 +413,7 @@ } /* connect */ - result = gnome_vfs_inet_connection_create (&conn->data_connection, + result = gnome_vfs_inet_connection_create (&data_connection, host, port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -424,16 +423,10 @@ return result; } - socket = gnome_vfs_inet_connection_to_socket (conn->data_connection); + socket = gnome_vfs_inet_connection_to_socket (data_connection); conn->data_socketbuf = gnome_vfs_socket_buffer_new (socket); - if (conn->socket_buf == NULL) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - return GNOME_VFS_ERROR_GENERIC; - } - - if (conn->offset) - { + if (conn->offset) { gchar *tmpstring; tmpstring = g_strdup_printf ("REST %Lu", conn->offset); @@ -441,8 +434,7 @@ g_free (tmpstring); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } } @@ -450,16 +442,14 @@ result = do_control_write (conn, command); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } result = get_response (conn); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } @@ -501,15 +491,10 @@ if(conn->data_socketbuf) { gnome_vfs_socket_buffer_flush (conn->data_socketbuf); - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); conn->data_socketbuf = NULL; } - if (conn->data_connection) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - conn->data_connection = NULL; - } - result = get_response (conn); return result; @@ -545,6 +530,7 @@ gint port = control_port; const gchar *user = anon_user; const gchar *pass = anon_pass; + GnomeVFSInetConnection* inet_connection; conn->uri = gnome_vfs_uri_dup (uri); conn->response_buffer = g_string_new (""); @@ -565,7 +551,7 @@ pass = gnome_vfs_uri_get_password (uri); } - result = gnome_vfs_inet_connection_create (&conn->inet_connection, + result = gnome_vfs_inet_connection_create (&inet_connection, gnome_vfs_uri_get_host_name (uri), port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -581,11 +567,11 @@ return result; } - conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (conn->inet_connection); + conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (inet_connection); if (conn->socket_buf == NULL) { g_warning ("Getting socket buffer failed"); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_inet_connection_destroy (inet_connection, NULL); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -612,8 +598,7 @@ /* login failed */ g_warning ("FTP server said: \"%d %s\"\n", conn->response_code, conn->response_message); - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -645,11 +630,8 @@ ftp_connection_destroy (FtpConnection *conn) { - if (conn->inet_connection) - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); - if (conn->socket_buf) - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_free (conn->cwd); @@ -659,11 +641,8 @@ g_free (conn->response_message); g_free (conn->server_type); - if (conn->data_connection) - gnome_vfs_inet_connection_destroy(conn->data_connection, NULL); - if (conn->data_socketbuf) - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); g_free (conn->dirlist); g_free (conn->dirlistptr); --=-vEputk1gGiSFtfo2JnkO-- From alexl@redhat.com Fri Jan 30 03:05:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 42D57182E3 for ; Fri, 30 Jan 2004 03:05:39 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Vb24660; Fri, 30 Jan 2004 03:05:31 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Ua05769; Fri, 30 Jan 2004 03:05:30 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0U853kC017335; Fri, 30 Jan 2004 03:05:04 -0500 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Alexander Larsson To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Message-Id: <1075449929.8585.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 30 Jan 2004 09:05:29 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > Hi, > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > agains ftp and http urls. > > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. Nah, it works. Christophe or I will get to it eventually. I'm just horribly busy with other stuff at the moment. Your first patch is tagged in my inbox and will get attention when i have time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded coffee-fuelled cop from a doomed world. She's a strong-willed thirtysomething Valkyrie descended from a line of powerful witches. They fight crime! From thomas.cataldo@aliacom.fr Fri Jan 30 03:13:22 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0901.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id C0FDC18FF9 for ; Fri, 30 Jan 2004 03:13:10 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0901.wanadoo.fr (SMTP Server) with ESMTP id 8EA02180021B; Fri, 30 Jan 2004 09:13:02 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id D1619106FD4; Fri, 30 Jan 2004 09:07:03 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Alexander Larsson Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075449929.8585.37.camel@localhost.localdomain> References: <1075428053.15247.11.camel@buffy> <1075449929.8585.37.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1075450023.15247.13.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 09:07:03 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 09:05, Alexander Larsson wrote: > On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > > Hi, > > > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > > agains ftp and http urls. > > > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > Nah, it works. Christophe or I will get to it eventually. I'm just > horribly busy with other stuff at the moment. Your first patch is tagged > in my inbox and will get attention when i have time. Ok, thanks for the quick reply. From root@cavtel.net Thu Jan 29 17:38:23 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from xx.mx.cavtel.net (xx.mx.cavtel.net [64.83.1.45]) by mail.gnome.org (Postfix) with ESMTP id 5A15618E5F; Thu, 29 Jan 2004 17:38:23 -0500 (EST) Received: by xx.mx.cavtel.net (Postfix, from userid 0) id CEE681D42C8; Thu, 29 Jan 2004 17:38:22 -0500 (EST) Received: from msg2.cavtel.net (msg2.mx.cavtel.net [64.83.1.144]) by xx.mx.cavtel.net (Postfix) with ESMTP id 96E8A4382D for ; Wed, 28 Jan 2004 06:17:55 -0500 (EST) Received: by msg2.cavtel.net (Postfix, from userid 1002) id B49283139E; Wed, 28 Jan 2004 06:02:41 -0500 (EST) Received: from mail.gnome.org (moniker.gnome.org [67.72.78.218]) by msg2.cavtel.net (Postfix) with ESMTP id 3E3E431B89 for ; Wed, 28 Jan 2004 05:58:12 -0500 (EST) Received: from moniker.gnome.org (moniker.gnome.org [127.0.0.1]) by mail.gnome.org (Postfix) with ESMTP id A8B08184D1; Wed, 28 Jan 2004 05:59:25 -0500 (EST) Delivered-To: desktop-devel-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Content-Transfer-Encoding: 7bit X-BeenThere: desktop-devel-list@gnome.org X-Loop: desktop-devel-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Date: 28 Jan 2004 18:39:13 +0800 X-Bayesian-Class: No, tests=bogofilter, spamicity=0.188133, version=0.15.8 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list From cfergeau@mipsys.com Fri Jan 30 04:11:12 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from bugsbunny.mipsys.com (griffon.mipsys.com [217.167.51.129]) by mail.gnome.org (Postfix) with ESMTP id 1651918A96 for ; Fri, 30 Jan 2004 04:11:12 -0500 (EST) Received: from teuf by bugsbunny.mipsys.com with local (Exim 3.36 #1 (Debian)) id 1AmUfU-0003Nj-00; Fri, 30 Jan 2004 10:10:28 +0100 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Christophe Fergeau To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1075453828.3843.0.camel@bugsbunny.mipsys.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.3 Date: Fri, 30 Jan 2004 10:10:28 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. I prefer having a bug report in addition to mails since I regularly check the pending bugs in bugzilla, and process them as I find time. Christophe From thomas.cataldo@aliacom.fr Fri Jan 30 04:37:20 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail.aliacom.fr (mail.aliacom.fr [213.41.82.82]) by mail.gnome.org (Postfix) with ESMTP id BCDC318FF1; Fri, 30 Jan 2004 04:37:19 -0500 (EST) Received: from chienne.aliacom-local (chienne.aliacom-local [192.168.1.38]) by mail.aliacom.fr (Postfix) with ESMTP id D2AE7202DC; Fri, 30 Jan 2004 10:37:17 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Christophe Fergeau Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075453828.3843.0.camel@bugsbunny.mipsys.com> References: <1075428053.15247.11.camel@buffy> <1075453828.3843.0.camel@bugsbunny.mipsys.com> Content-Type: text/plain Organization: Aliacom Message-Id: <1075455508.14823.17.camel@chienne.aliacom-local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 10:38:28 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 10:10, Christophe Fergeau wrote: > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > I prefer having a bug report in addition to mails since I regularly > check the pending bugs in bugzilla, and process them as I find time. My two patches (nttp and ftp/http leaks) are filed as bugs #132950 and #132951 regards, Thomas. From jitendra.moon@wipro.com Sun Jan 4 04:11:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by mail.gnome.org (Postfix) with ESMTP id 4E185185D5 for ; Sun, 4 Jan 2004 04:11:51 -0500 (EST) Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i049BnOZ025386 for ; Sun, 4 Jan 2004 14:41:49 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Sun, 04 Jan 2004 14:42:58 +0530 Received: from chn-snr-bh3.wipro.com ([10.145.50.93]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from hyd-mdp-msg.wipro.com ([10.150.50.99]) by chn-snr-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from mdpnok109242 ([192.168.142.126]) by hyd-mdp-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Reply-To: From: "Jitendra Moon" To: Date: Sun, 4 Jan 2004 14:46:14 +0530 Message-ID: <000601c3d2a3$67495ff0$b786a8c0@mdpnok109242> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3D2D1.81019BF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 04 Jan 2004 09:11:48.0301 (UTC) FILETIME=[C8450FD0:01C3D2A2] Subject: (no subject) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 I have installed gnome-vfs-2.0 on my debian box. Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs API=92s. Any sample code in this regard will be of great help. =20 Are only gnome vfs libraries sufficient to access above mentioned device file systems on debian Linux? Or do we need to install some thing more on top of gnome VFS? =20 Again any sample code will be of great help. =20 =20 =20 Jitendra Moon =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I have installed gnome-vfs-2.0 on my debian = box.

Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs = API’s.

Any sample code in this regard will be of great = help.

 

Are only gnome vfs libraries sufficient to access = above mentioned device file systems on debian = Linux?

Or do we need to install some thing more on top of = gnome VFS?

 

Again any sample code will be of great = help.

 

 

 

Jitendra Moon

 

 

 

 

 

 

 

 

 

 

 

 

 

------=_NextPart_000_0007_01C3D2D1.81019BF0-- From ejk@ucsc.edu Fri Jan 2 17:47:02 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by mail.gnome.org (Postfix) with ESMTP id EF43B18448; Fri, 2 Jan 2004 17:47:01 -0500 (EST) Received: from [169.233.37.23] (k-d0789.resnet.ucsc.edu [169.233.37.23]) by ucsc.edu (8.10.1/8.10.1) with ESMTP id i02MhLx01991; Fri, 2 Jan 2004 14:43:23 -0800 (PST) Subject: Re: Suggestion for file type detection approach From: Edward Jay Kreps Reply-To: Suggestion.for.file.type.detection.approach@ucsc.edu To: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org, gnome-vfs-list@gnome.org Content-Type: text/plain Message-Id: <1073083582.3530.77.camel@whipple> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 14:46:22 -0800 Content-Transfer-Encoding: 7bit X-UCSC-CATS-MailScanner: Found to be clean X-UCSC-CATS-MailScanner-SpamCheck: Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: >Given the performance bottleneck imposed by sniffing, I suggest that it >is not used anymore in directory listing routines. It should be used >when the user tries to open an unknown file. Let's imagine this case: I don't think this is a good way of thinking about things. The questions are: 1. Is sniffing a good idea? 2. If so does it work correctly? 3. If (1) and (2), is it performing fast enough? I think others have argued persuasively that sniffing is a good idea since unix doesn't generally give file name suffixes to files (even though gnome does), and often files have incorrect suffixes. A number of people have said that there are instances where sniffing is not correctly determining the file type. If true, this is an excellent argument for fixing those cases, but not at all an argument for throwing away sniffing altogether. >From your benchmarking it is clear that (3) is a problem, and sniffing is taking too long. This is not an argument for getting rid of it though, just an argument for speeding it up. Someone suggested running it through a profiler, but I doubt that will be worthwhile--the problem is almost certainly the multiple disk accesses (your disk is having to seek for each file). As others have pointed out, a two pass technique. based on extension and then sniffing is also a bad idea since icons, etc would change in the case of a discrepancy. Sniffing is slow because it opens every file and reads some of it every time you open a given directory. If you want to make this fast, cache filetypes; now opening the huge mp3 folder is just a matter of reading a single cache file and sniffing those files with a modification time later than that of the cache file. Naturally this would only need to be done for those really huge directories, it would probably be a waste for directories with only a hundred files or fewer. I don't think we need to worry about which approach is ultimately going to perform faster. For a program like Nautilus either there is or is not a human-noticeable lag time; improving performance when there is no lag time is totally pointless. A number of people have used Windows as an example of why we don't need to sniff files; though there are a number of features in Windows worth copying this is definitely not one of them. I have worked on some commercial software and the number one frivolous bug report or unfixable user issue occurs when the user attempts to open a file that has an incorrect filename extension. People on this list have suggested that this is a user problem not a software problem (i.e. that the user was stupid and beyond help), but I can assure you that however obvious the connection between the hidden Windows filename extension and the error message that our program gave is to me and you, it was not obvious to a large number of otherwise very intelligent people who just weren't as knowledgeable about computers. People always think that the icon for a file is somehow part of the file (it makes sense if you don't think about it too hard), and so if a file has, say, a jpeg icon it doesn't occur to them that it is not a jpeg. -Jay From dionney@hotmail.com Fri Jan 2 19:58:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from dionney.dyndns.org (modemcable253.38-203-24.mc.videotron.ca [24.203.38.253]) by mail.gnome.org (Postfix) with ESMTP id B0854182E2; Fri, 2 Jan 2004 19:58:08 -0500 (EST) Received: from [127.0.0.1] (dionney.dyndns.org [127.0.0.1]) by dionney.dyndns.org (Postfix) with ESMTP id F2F9CFD65; Fri, 2 Jan 2004 19:57:59 -0500 (EST) Subject: Re: Suggestion for file type detection approach From: Yves Dionne To: gnome-vfs-list@gnome.org Cc: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1072403221.945.61.camel@hermes.intra.gs2.com.br> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> Content-Type: multipart/mixed; boundary="=-uazmxkOo5iyZC9kUE0ez" Message-Id: <1073091476.23189.12.camel@dionney.dyndns.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 19:57:58 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-uazmxkOo5iyZC9kUE0ez Content-Type: text/plain; charset= Content-Transfer-Encoding: 8bit On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > Why not support recording the mime-type of a file as meta-data (EA) on > > filesystems that support it (every one of them at this point?). It > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > to clearly be the right way to do it. If GNOME VFS supported it then > > it seems it would be easy to implement for alot of applications. > > > > I agree with you, but while we must provide a quick solution, EA (and > the attributes themselves) must be standardized cross-unix and > cross-desktop. This will take some time to mature, since the mechanisms > for sending files through the Internet (between computers, in general) > must mature to support EA. I never used Apple operating systems, but it > looks like they have such a mechanism. Nothing that a tar with EA > support could not do. > > GNOME must provide room today to support state-of-the-art technologies > in the future, but must at the same time provide solutions to today's > users using today's technologies. > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. I thought this could be fun, so hacked gnome-vfs to save the mime type on a EA named "mime_type". When trying to find the mime type for the file, gnome-vfs will first check if this EA exists. If so, use that for the mime type. If not, determine the mime type as usual and save it. It works only for local files. If you don't have permission to change the file, the EA will not be saved. And you need a file system which support EA, of course. I tested it with ext3. Might work with others too. This is a hack, just an exercise to see if it could be beneficial. I did this just for fun. I did not try to follow coding standards, I have no intention of maintaining this patch. Although I might try to hack nautilus to allow changing the mime type (as recorded in the EA). The following patch is against gnome-vfs-2.4.1 as found in Fedora. I attach also a modified SPEC file, just in case someone wants to build it. --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs-2.4.1-attr.patch Content-Type: text/x-patch; name=gnome-vfs-2.4.1-attr.patch; charset= Content-Transfer-Encoding: 7bit diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h gnome-vfs-2.4.1/acconfig.h --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h 2003-09-27 11:42:49.000000000 -0400 +++ gnome-vfs-2.4.1/acconfig.h 2004-01-02 17:11:36.665008680 -0500 @@ -15,6 +15,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in gnome-vfs-2.4.1/config.h.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in 2003-09-01 14:32:48.000000000 -0400 +++ gnome-vfs-2.4.1/config.h.in 2004-01-02 17:11:36.667008376 -0500 @@ -16,6 +16,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in gnome-vfs-2.4.1/configure.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in 2003-10-12 06:51:55.000000000 -0400 +++ gnome-vfs-2.4.1/configure.in 2004-01-02 17:11:36.671007768 -0500 @@ -482,6 +482,22 @@ +dnl *********************** +dnl *** Checks for ATTR *** +dnl *********************** + +ATTR_MISSING_WARNING="Gnome-vfs depends on ATTR" +ATTR_LIBS= +AC_CHECK_LIB(attr, attr_getf, + [AC_CHECK_HEADERS(attr/attributes.h, + [AC_DEFINE(HAVE_ATTR) + ATTR_LIBS="-lattr"], + AC_MSG_WARN(*** ATTR support will not be built (header files not found) $ATTR_MISSING_WARNING ***))], + AC_MSG_WARN(*** ATTR support will not be built (ATTR library not found) $ATTR_MISSING_WARNING ***)) +AC_SUBST(ATTR_LIBS) + + + dnl ************************** dnl *** Checks for gtk-doc *** dnl ************************** diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2003-09-27 11:42:51.000000000 -0400 +++ gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2004-01-02 17:15:50.041489600 -0500 @@ -39,6 +39,9 @@ #include #include #include +#ifdef HAVE_ATTR +#include +#endif static gboolean module_inited = FALSE; @@ -80,6 +83,40 @@ #endif /* G_LOCK_DEFINE_STATIC */ +#ifdef HAVE_ATTR +static GList *mime_attr = NULL; + +static const char * +get_mime_from_ea (FILE *file) +{ + char * mime_type = NULL; + char * buffer = g_alloca (256+1); + GList * p; + int len = 256; + + if (attr_getf (fileno (file), "mime_type", buffer, &len, 0) == 0) { + buffer[len] = 0; + G_LOCK (mime_mutex); + p = g_list_find_custom (mime_attr, buffer, g_ascii_strcasecmp); + if (p != NULL) { + mime_type = p->data; + } else { + mime_type = g_strdup (buffer); + mime_attr = g_list_insert_sorted (mime_attr, mime_type, g_ascii_strcasecmp); + } + G_UNLOCK (mime_mutex); + } + return mime_type; +} + +static void +set_mime_from_ea (FILE *file, const char *mime_type) +{ + int len = strlen (mime_type); + + attr_setf (fileno (file), "mime_type", mime_type, len, 0); +} +#endif static char * get_priority (char *def, int *priority) @@ -337,6 +374,13 @@ g_list_free (mime_regexs [i]); mime_regexs [i] = NULL; } +#ifdef HAVE_ATTR + for (p = mime_attr; p != NULL; p = p->next) { + g_free (p->data); + } + g_list_free (mime_attr); + mime_attr = NULL; +#endif } static void @@ -714,11 +758,22 @@ } if (file != NULL) { +#if HAVE_ATTR + result = get_mime_from_ea (file); + if (result == NULL) + { +#endif buffer = _gnome_vfs_mime_sniff_buffer_new_generic (file_seek_binder, file_read_binder, file); result = _gnome_vfs_get_mime_type_internal (buffer, path); gnome_vfs_mime_sniff_buffer_free (buffer); +#ifdef HAVE_ATTR + if (result != NULL) { + set_mime_from_ea (file, result); + } + } +#endif fclose (file); } else { result = _gnome_vfs_get_mime_type_internal (NULL, path); diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am gnome-vfs-2.4.1/libgnomevfs/Makefile.am --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:10:48.860276104 -0500 +++ gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:11:36.679006552 -0500 @@ -37,6 +37,7 @@ libgnomevfs_2_la_LIBADD = \ $(LIBGNOMEVFS_LIBS) \ + $(ATTR_LIBS) \ $(NULL) libgnomevfs_2_la_LDFLAGS = \ --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs2.spec Content-Type: text/plain; name=gnome-vfs2.spec; charset= Content-Transfer-Encoding: 8bit %define libbonobo_version 2.2.0 %define gconf2_version 1.2.0 %define gtkdoc_version 0.9 %define gnome_mime_data_version 2.0.0-11 %define redhat_menus_version 0.30 %define po_package gnome-vfs-2.0 Summary: The GNOME virtual file-system libraries. Name: gnome-vfs2 Version: 2.4.1 Release: 1 License: LGPL Group: System Environment/Libraries Source: gnome-vfs-%{version}.tar.bz2 Source2: vfolder-desktop-method.c Source3: desktop-method.c URL: http://www.gnome.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-root Requires: gnome-mime-data >= %{gnome_mime_data_version} Requires: redhat-menus >= %{redhat_menus_version} BuildRequires: libbonobo-devel >= %{libbonobo_version} BuildRequires: GConf2-devel >= %{gconf2_version} BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: bonobo-activation-devel, glib2-devel, libxml2-devel, zlib-devel BuildRequires: popt, bzip2-devel, ORBit2-devel, XFree86-devel, openjade BuildRequires: pkgconfig BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: /usr/bin/automake-1.4 BuildRequires: gtk-doc >= %{gtkdoc_version} Prereq: GConf2 >= %{gconf2_version} Patch1: gnome-vfs-1.9.4.91-docdir.patch Patch2: gnome-vfs-2.1.3-moved-menu-files.patch Patch3: gnome-vfs-2.0.4-onlyshowin.patch Patch5: gnome-vfs-1.9.16-moved-menu-files.patch Patch6: gnome-vfs-2.0.1-only-show-in.patch Patch7: gnome-vfs-2.3.7-modules-conf.patch Patch8: gnome-vfs-2.0.2-newstat.patch Patch9: gnome-vfs-2.0.2-read-only.patch ## this is the automake-requiring patch Patch10: gnome-vfs-2.1.6-old-modules.patch Patch11: gnome-vfs-2.1.6-network-uri.patch Patch12: gnome-vfs-2.1.6-never-show-if-empty.patch Patch13: gnome-vfs-2.1.6-hide-with-empty-subfolders.patch Patch14: gnome-vfs-2.1.6-no-private-methods.patch Patch15: gnome-vfs-2.2.0-vfolder-hacks.patch Patch16: gnome-vfs-2.4.1-attr.patch %description GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for file systems, http, ftp, and others. It provides a URI-based API, backend supporting asynchronous file operations, a MIME type manipulation library, and other features. %package devel Summary: Libraries and include files for developing GNOME VFS applications. Group: Development/Libraries Requires: %{name} = %{version} Requires: GConf2-devel >= %{gconf2_version} Requires: libbonobo-devel >= %{libbonobo_version} Conflicts: bonobo-devel < 1.0.8 Conflicts: gnome-vfs-devel < 1.0.2 %description devel This package provides the necessary development libraries for writing GNOME VFS modules and applications that use the GNOME VFS APIs. %prep %setup -q -n gnome-vfs-%{version} cp -f %{SOURCE2} modules cp -f %{SOURCE3} modules # Patch1: gnome-vfs-1.9.4.91-docdir.patch modifies doc/Makefile.am #%patch1 -p1 -b .docdir (cd modules && cp default-modules.conf default-modules.conf.with-menu-editing) ## clean out the methods that don't work with our setup DMC=modules/default-modules.conf.with-menu-editing perl -pi -e 's/all-applications:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/all-preferences:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/favorites:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/network:\s+libvfolder-desktop.so//g' $DMC ## these two should actually work ## perl -pi -e 's/applications-all-users:\s+libvfolder-desktop.so//g' $DMC ## perl -pi -e 's/preferences-all-users:\s+libvfolder-desktop.so//g' $DMC ## these are now in the vfolder-hacks patch #%patch2 -p1 -b .moved-menu-files #%patch3 -p0 -b .onlyshowin %patch5 -p1 -b .moved-menu-files %patch6 -p1 -b .only-show-in %patch7 -p1 -b .modules-conf %patch8 -p1 -b .newstat %patch9 -p1 -b .read-only %patch10 -p1 -b .old-modules %patch11 -p1 -b .network-uri %patch12 -p1 -b .never-show-if-empty %patch13 -p1 -b .hide-with-empty-subfolders %patch14 -p1 -b .no-private-methods %patch15 -p0 -b .vfolder-hacks %patch16 -p1 -b .attr %build # needed for patch10 (changing makefile to old vfolder backend) automake-1.4 # needed for patch16 (changing configure.in for EA) autoconf if pkg-config openssl ; then CPPFLAGS=`pkg-config --cflags openssl`; export CPPFLAGS LDFLAGS=`pkg-config --libs-only-L openssl`; export LDFLAGS fi %configure export tagname=CC make LIBTOOL=/usr/bin/libtool %install rm -fr %{buildroot} export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 export tagname=CC %makeinstall LIBTOOL=/usr/bin/libtool unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL rm -f $RPM_BUILD_ROOT%{_libdir}/gnome-vfs-2.0/modules/lib*.a rm -f $RPM_BUILD_ROOT%{_libdir}/*.la rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default ## why, dear god, why? rm -f $RPM_BUILD_ROOT%{_datadir}/aclocal/gob2.m4 install -m 644 modules/default-modules.conf.with-menu-editing $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/ ## Remove this line and update file list to revert to ## no-menu-editing-by-default # (cd $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/; mv default-modules.conf default-modules.conf.without-menu-editing; mv default-modules.conf.with-menu-editing default-modules.conf) rm -f $RPM_BUILD_ROOT%{_libdir}/bonobo/monikers/*.{a,la} %find_lang %{po_package} %clean rm -fr %{buildroot} %post export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` SCHEMAS="system_http_proxy.schemas" for S in $SCHEMAS; do gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/$S > /dev/null done /sbin/ldconfig %postun -p /sbin/ldconfig %files -f %{po_package}.lang %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README %dir %{_sysconfdir}/gnome-vfs-2.0 %dir %{_sysconfdir}/gnome-vfs-2.0/modules #%dir %{_sysconfdir}/gnome-vfs-2.0/vfolders %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf.with-menu-editing ## we aren't really using the .vfolder-info config files, ## so installing them is a little misleading. ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default %{_bindir}/* %{_libdir}/*.so.* %{_libdir}/gnome-vfs-2.0/modules %dir %{_libdir}/gnome-vfs-2.0 %{_libdir}/bonobo %{_libdir}/vfs %{_sysconfdir}/gconf/schemas/* ## conflicts with gnome-vfs 1, ignore for now ## %{_datadir}/man/man5/* %files devel %defattr(-, root, root) %{_libdir}/lib*.a %{_libdir}/lib*.so %{_libdir}/pkgconfig/* %{_libdir}/gnome-vfs-2.0/include/*.h %{_includedir}/* %{_datadir}/gtk-doc %changelog * Wed Oct 15 2003 Alexander Larsson 2.4.1-1 - Update to 2.4.1, fixes bug #107130 * Tue Sep 9 2003 Alexander Larsson 2.4.0-1 - update to 2.4.0 * Tue Sep 2 2003 Alexander Larsson 2.3.90-1 - update to 2.3.90 * Mon Aug 25 2003 Alexander Larsson 2.3.8-1 - update to 2.3.8 * Mon Aug 11 2003 Alexander Larsson 2.3.7-1 - update for gnome 2.3 * Tue Jul 22 2003 Nalin Dahyabhai 2.2.5-3 - rebuild, setting tagname to CC * Tue Jul 8 2003 Alexander Larsson 2.2.5-2.E - Rebuild * Wed Jun 04 2003 Elliot Lee - rebuilt * Tue May 27 2003 Alexander Larsson 2.2.5-1 - Update to 2.2.5 * Mon Mar 31 2003 Alexander Larsson 2.2.4-1 - Update to 2.2.4 * Mon Feb 24 2003 Elliot Lee - debuginfo rebuild * Mon Feb 24 2003 Alexander Larsson 2.2.2-3 - Added patch to fix smb crash (#84982) * Mon Feb 24 2003 Alexander Larsson 2.2.2-2 - Add patch to fix notify race (#84668) * Wed Feb 12 2003 Alexander Larsson 2.2.2-1 - 2.2.2, fixes bad memleak (#83791) * Tue Feb 11 2003 Havoc Pennington 2.2.1-3 - kill menu editing again, it was very very broken * Mon Feb 10 2003 Bill Nottingham 2.2.1-2 - fix file list (#68226) - prereq GConf2 * Mon Feb 10 2003 Alexander Larsson 2.2.1-1 - Update to 2.2.1. fixes gnome-theme-manager hang * Thu Feb 6 2003 Havoc Pennington 2.2.0-7 - move to menu editing modules.conf by default, we'll see if it works * Tue Jan 28 2003 Matt Wilson 2.2.0-6 - use LIBTOOL=/usr/bin/libtool * Mon Jan 27 2003 Havoc Pennington - it would help to *install* the stupid menu edit conf file - update the vfolder-hacks patch with some fixes * Fri Jan 24 2003 Havoc Pennington - hack up editable vfolder backend to maybe work (still not the default config file) * Wed Jan 22 2003 Havoc Pennington - include a non-default config file to use new vfolder method - build the new vfolder method * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 21 2003 Alexander Larsson - Update to 2.2.0 * Mon Jan 13 2003 Havoc Pennington - variation on the subfolders hack to try to fix it * Sat Jan 11 2003 Havoc Pennington - fix bug where empty folders with empty subfolders would still be visible. * Sat Jan 11 2003 Havoc Pennington - finish adapting desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - adapt desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - hardcode , it's stupid to ever override this. * Sat Jan 11 2003 Havoc Pennington - make network:/// use libdesktop.so, and modify libdesktop.so to support it * Sat Jan 11 2003 Havoc Pennington - Revert to George's vfolder backend from gnome-vfs-2.0.2 or so - put back libdesktop.so - don't build the new vfolder backend * Wed Jan 8 2003 Alexander Larsson 2.1.6-2 - Removed __libdir fix that was fixed upstream * Wed Jan 8 2003 Alexander Larsson 2.1.6-1 - Update to 2.1.6 * Tue Jan 7 2003 Nalin Dahyabhai 2.1.5-3 - rebuild * Mon Dec 16 2002 Tim Powers 2.1.5-2 - rebuild * Mon Dec 16 2002 Alexander Larsson 2.1.5-1 - Update to 2.1.5 * Thu Dec 12 2002 Nalin Dahyabhai - use OpenSSL's pkg-config information, if available * Wed Dec 4 2002 Havoc Pennington - 2.1.3.1 * Sun Nov 10 2002 Havoc Pennington - 2.1.3 - update moved-menu-files patch * Wed Oct 23 2002 Havoc Pennington - add patch for OnlyShowIn support - use plain menu files for .vfolder-info-default - don't install unused vfolder-info files * Tue Oct 8 2002 Havoc Pennington - require new gnome-mime-data in proper libdir - 2.0.4 - drop most patches as they are now upstream or don't apply to new vfolder code * Fri Aug 30 2002 Owen Taylor - Backport a gnome-vfs locking fix from CVS (Hopefully fixes #71419) * Fri Aug 23 2002 Havoc Pennington - make vfolder method read-only #72208 * Mon Aug 19 2002 Jonathan Blandford - notice when new files are installed * Tue Aug 13 2002 Havoc Pennington - don't include pointless .a files * Fri Aug 2 2002 Havoc Pennington - 2.0.2 - use vfolders for system-settings and server-settings * Tue Jul 16 2002 Havoc Pennington - fix OnlyShowIn * Tue Jun 25 2002 Owen Taylor - Version 2.0.1, fix missing po files * Sun Jun 16 2002 Havoc Pennington - 2.0.0 - put schema files in file list, and install them - put libdir/vfs in file list * Tue Jun 11 2002 Havoc Pennington - rebuild in different environment * Tue Jun 11 2002 Havoc Pennington - look for menus in redhat-menus * Fri Jun 07 2002 Havoc Pennington - rebuild in different environment * Wed Jun 5 2002 Havoc Pennington - 1.9.16 * Sun May 26 2002 Tim Powers - automated rebuild * Mon May 20 2002 Havoc Pennington - rebuild in different environment * Mon May 20 2002 Havoc Pennington - 1.9.15 - comment out docdir patch for now * Fri May 3 2002 Havoc Pennington - 1.9.14 * Thu Apr 4 2002 Jeremy Katz - 1.9.11 - update file list * Thu Feb 14 2002 Havoc Pennington - 1.9.7 * Thu Jan 31 2002 Owen Taylor - Fix location of installed docs not to conflict with gnome-vfs1 * Wed Jan 30 2002 Owen Taylor - Rebuild with new libs * Wed Jan 09 2002 Tim Powers - automated rebuild * Thu Jan 3 2002 Havoc Pennington - 1.0.4.91 snap * Mon Nov 26 2001 Havoc Pennington - 1.9.4.90 snap - require gnome-mime-data * Sun Oct 28 2001 Havoc Pennington - new snap, rebuild for glib 1.3.10 * Fri Oct 5 2001 Havoc Pennington - cvs snap * Fri Sep 21 2001 Havoc Pennington - rebuild cvs snap with changes merged upstream - fix a requires - fix up requires/buildrequires a bit * Tue Sep 18 2001 Havoc Pennington - initial gnome-vfs2 build, remove all patches - change config files not to be noreplace * Mon Aug 27 2001 Havoc Pennington - Add po files from sources.redhat.com * Mon Aug 20 2001 Havoc Pennington - fix #51864 (Gimp can't handle file: URIs) * Mon Aug 20 2001 Alexander Larsson 1.0.1-15 - Moved gnome-conf and pkgconfig files to the devel package - Fixes SHOULD-FIX bug #49795 * Mon Aug 6 2001 Alexander Larsson 1.0.1-14 - Added a patch that fixed AbiWord mimetype handling. * Fri Jul 27 2001 Jonathan Blandford - Add .desktop file sniffing * Tue Jul 24 2001 Havoc Pennington - don't do the giant trash scan thing; did not play nice with NFS. * Tue Jul 24 2001 Havoc Pennington - fix desktop-file.conf file * Tue Jul 24 2001 Havoc Pennington - change some URI scheme names * Fri Jul 20 2001 Alexander Larsson - Add pkgconfig and gnome-libs-devel build reqs. - Remove dependency on gnome-vfs-devel by doing some - CPPFLAGS and LDFLAGS magic * Wed Jul 11 2001 Havoc Pennington - add missing directories * Tue Jul 10 2001 Havoc Pennington - fix a segv - change which dirs the desktop VFS module points to * Sun Jul 08 2001 Havoc Pennington - add desktop VFS module hack * Fri Jul 6 2001 Trond Eivind Glomsrød - Remove Distribution and Vendor - Make the config files noreplace - Move .so links to devel subpackage - langify - Add BuildRequires - Don't mess with /etc/ld.so.conf - Use %%{_tmppath} - s/Copyright/License/ * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild. * Wed May 9 2001 Jonathan Blandford - New Version. * Tue Apr 17 2001 Jonathan Blandford - New Version. - clean up spec file some. * Mon Feb 19 2001 Gregory Leblanc - fix paths and macros * Tue Feb 22 2000 Ross Golder - Integrate into source tree --=-uazmxkOo5iyZC9kUE0ez-- From awilliam@whitemice.org Sun Jan 4 08:13:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mail.gnome.org (Postfix) with ESMTP id 7965F183D4; Sun, 4 Jan 2004 08:13:09 -0500 (EST) Received: from adsl-68-72-14-103.dsl.klmzmi.ameritech.net ([68.72.14.103] helo=estate1.whitemice.org) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ad840-0004TY-00; Sun, 04 Jan 2004 05:13:04 -0800 Received: from estate2.whitemice.org (estate2.whitemice.org [192.168.3.245]) by estate1.whitemice.org (8.12.5/8.12.5) with ESMTP id i04DGaAC007033; Sun, 4 Jan 2004 08:16:36 -0500 Subject: Re: Suggestion for file type detection approach From: Adam Williams To: Yves Dionne Cc: gnome-vfs-list@gnome.org, nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain Message-Id: <1073221987.5722.64.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 08:13:07 -0500 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. Yes, please! I mentioned EA awhile ago to no response; sniff, look at extensions, whatever - and keep your results. Even better if applications that created files put the EA tags in themselves. This is so obviously the right solution - Mac OS has been doing this forever, and Winblows is starting to make real use of EA as well. EA follow the file when copied, moved, etc... You could even store a thumbnail in EA and not generate one every time or cache it somewhere annoying like ".nautilus". > It works only for local files. Not sure this is true. The EA on NTFS can be accessed by CIFS calls, and NFSv4 at least supports extended attributes. But maybe niether are ture on Linux at this point. > If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. Works with ext3, XFS, and JFS (at least). > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. Excellent. From dobey@free.fr Sun Jan 4 12:19:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id 1926718685 for ; Sun, 4 Jan 2004 12:19:14 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdBtq-0007Aa-0W; Sun, 04 Jan 2004 12:18:50 -0500 Subject: Re: FUD about security and file extensions (was Re: Why file content sniffing sucks) From: Rodney Dawes To: "Jason A. Pfeil" Cc: Charles Goodwin , Fabio Gomes , Colin Walters , gnome-vfs-list@gnome.org In-Reply-To: References: <1072278440.1486.125.camel@hermes.intra.gs2.com.br> <20031224154241.GK1205@lazarus> <1072281561.4971.11.camel@firebrand> <1072283138.1087.26.camel@discomachinegun.prettypeople.org> <1072291008.15811.3.camel@nexus.verbum.private> <1072401563.945.33.camel@hermes.intra.gs2.com.br> <1072403078.27575.20.camel@mightymax.charlietech.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1073236729.26544.144.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:18:49 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On H=C3=ABn , 2003-12-29 at 10:21, Jason A. Pfeil wrote: > On Fri, 26 Dec 2003, Charles Goodwin wrote: > [...snip...] > > Yes, file sniffing is slow. So implement it in a way that does not > > affect the user. Last time I used Nautilus, I could scroll up and down > > and jump between folders without extra pause, whilst Nautilus updates > > itself in the background. So what is the issue? It only updates what > > is in immediate view (as I recall) so you just scroll to your desired > > file and, if necessary, wait the 2s for it to be detected. >=20 > I think that this is how it was supposed to be implemented, but I don't > believe that this implementation has actually been done. As a quick test= , > open /usr/bin in nautilus. On the box I am using to write this, /usr/bin > has 2,124 files in it. Nautilus took about 10 seconds to load the > contents of that directory. In comparison, use a shell and cd to /usr/bi= n. > Then, type the command: >=20 > echo * >=20 > and see how much faster that returns. echo * returned instantly on my bo= x. > If you want, you can do the echo * method first just so you can convince > yourself that nautilus is not caching things for the shell. And how do I convince myself that echo is doing all of the same activities that nautilus is? Doing a simple "echo *" has substantially less traffic to the X server. It doesn't tell you mime types, modification times, number of files in the child directories, or anything extra about the files. Hell, it doesn't even put the filenames on new lines. If you want to make a comparison like this for mime types, then either compare file and test-mime from the gnome-vfs tests/ directory, on a terminal, while redirecting STDIN and STDOUT to /dev/null, so that terminal X traffic and rendering speed doesn't come in to play. Then you should see that it is not the mime type detection that is slow. The gnome-vfs mime test and file take about the same time to complete. It took less than half a second for gnome-vfs to get the mime types of over 619 files on my system. > Also, when nautilus is opening the directory, take note of the extreme di= sk > churning you hear and note its absence when using the echo * command. FY= I, > the hardware I ran this on is a 1.8GHz P4 with 1GB RAM and U160 SCSI disk > on an Adaptec 7892A controller. Hardly pokey by any standards. Yes. The "echo *" command doesn't open any files at all. It's all done in the command line shell. It simply expands * to all filenames in the current directory, and spits them out on STDOUT. It is not doing anything complex at all. Maybe you should fix The GIMP to use "echo *" when it starts up. It takes a long time to load all those plug-ins. > If we want the average user to use Linux over Windows, we have to have a > system that is competitive not only in security, but also in speed. Whil= e > nautilus has improved greatly over the years, it is still *far* behind > explorer in speed and this file-type identification issue is a prime reas= on. s/Linux/GNOME/ Linux in general is as fast as, if not faster than, Windows. Nautilus is also just as fast as Explorer. Saying X is faster than Y because Y is doing more is ignorant. If Nautilus is slower than Explorer for you, it is a configuration issue, not an issue of how it detects the mime types. You really should spend your time profiling the GNOME libraries and Nautilus if you think your statement is true. Stating your opinion of what is wrong with it won't get it fixed. Proving where the speed bottlenecks are with profiling data and real comparisons with more constants than the hardware it was run on, will be much more useful. > > If Nautilus is wrongly detecting a file type it is a _bug_ and should b= e > > dealt with as such. It is nothing to do with the system used by > > Nautilus. Detection of type by file extension is far more error prone > > and relies much more on correctness of user input which is an > > unreasonable expection on lay users. >=20 > I dispute this notion. Proper training of users (not unreasonable) with = the > help of applications automatically setting file-types will go a long way > towards having good input from users. You can't claim a dispute and then agree. Reasonable training and application assistance will go a long way, yes. However, we shouldn't be relying on user-training. We should be writing applications that help the user to learn on their own. Psychology is a very important aspect to usability. Having a user do something on their own instills pride. Don't you feel like doing more when you do something yourself, as opposed to having to spend $1200 to learn to write a basic web page? Our applications should be smart enough to let the users know what they are doing, and if what they are doing is correct. Also, people migrating from Windows or Mac OS have a bit of training. They generally know enough about icon/label->action associations and similar, that they can figure out things fairly quickly. > [...snip...] > > > The bugs present in Micros~1 Windows are not due to file type detecti= on > > > by suffix.=20 > >=20 > > Wrong, they are. By due nature of the ridiculous method, people > > associate .jpg files or .gif files as images. This introduces a proble= m > > with visual association. > > Somebody gets an email with an attachment such as 'pretty.jpg.exe' or > > 'sexy.gif.pl' and they open it up. Yes, this is due to file type > > detection by suffix because you are subconciously causing people to > > recognise file types by file suffix and hence they can be easily > > mislead. > However, in this type of example, the extensions for both of these files > are .exe and .pl, respectively. Therefore there is no ambiguity since a > file ending in .exe is not a file ending in .jpg and a file ending in .pl > is not a file ending in .gif. The only time that this can cause a proble= m > is when the system *hides* the extension like Windows does. This is a > badly contrived example. No. It goes beyond hiding the extension. Many versions of the file system also only support a maximum of one period in the filename. This really causes problems. The suffix detection also plays a major role, but it is not the only contributing factor. > [...snip...] > >=20 > > One goal of Gnome is to make Free Software desktops a global reality (a= s > > if it already isn't). Introducing notions that add to the confusion > > just to save a few cpu cycles and/or to make things look snappier > > on-the-surface is no way to achieve that goal; unless you want a buggy, > > insecure system but that niche is already well filled. >=20 > Or unless you want to have widespread use. Unfortunately, the average us= er > expects a computer to be fast. By coupling the file extension method wit= h > a type-match check method when the file is opened using nautilus, you get > the best of both worlds. I fail to see the objection. It's just as fast > as the way Windows does it, and it's just as secure as the current way > that nautilus does it. Contriving a conflict is counter-productive. We do have widespread use. Not as widespread as, say, Windows, but still, we have many a user. That user-base is only increasing, as well. The average user does not expect their computer to be as fast as you claim. The average user, uses Windows. Windows is by no means fast. Using both methods of file type detection will gain us nothing. In fact, we already do use both methods. The suffix checking is generally a fall-back method, though. Read the code. It's right there in plain sight. Contriving conflicts is indeed counter-productive. Please stop. :) > > I wish this pointless discussion would go away. It's clogging up my > > inbox. Really, there's some damn clever guys hacking Gnome and this >=20 > You can always unsubscribe to the list or request to get messages in a > digest. However, terminating a discussion because it bores you or is a > minor inconvenience to you is not the right approach. > [...snip...] It's not only an annoyance to him. These mails have been going to far more lists than they should have, if any at all. Continuing a thread simply so that it does go on, is also not the right approach. -- dobey From dobey@free.fr Sun Jan 4 12:47:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id AFA641853E for ; Sun, 4 Jan 2004 12:47:52 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdCLf-0007BI-Ij; Sun, 04 Jan 2004 12:47:35 -0500 Subject: Re: Suggestion for file type detection approach From: Rodney Dawes To: ejk@ucsc.edu Cc: gnome-vfs-list@gnome.org In-Reply-To: <1073083582.3530.77.camel@whipple> References: <1073083582.3530.77.camel@whipple> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1073238454.26541.173.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:47:35 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > >Given the performance bottleneck imposed by sniffing, I suggest that it > >is not used anymore in directory listing routines. It should be used > >when the user tries to open an unknown file. Let's imagine this case: > > I don't think this is a good way of thinking about things. The questions are: > 1. Is sniffing a good idea? > 2. If so does it work correctly? > 3. If (1) and (2), is it performing fast enough? > > I think others have argued persuasively that sniffing is a good idea > since unix doesn't generally give file name suffixes to files (even > though gnome does), and often files have incorrect suffixes. > > A number of people have said that there are instances where sniffing is > not correctly determining the file type. If true, this is an excellent > argument for fixing those cases, but not at all an argument for throwing > away sniffing altogether. I've only seen one person say that. And as I understand, no real information was provided. Only a comment of "it broke on this one file." But yes, it is a good argument for improving the system, not removing the core functionality. > >From your benchmarking it is clear that (3) is a problem, and sniffing > is taking too long. This is not an argument for getting rid of it > though, just an argument for speeding it up. Someone suggested running > it through a profiler, but I doubt that will be worthwhile--the problem > is almost certainly the multiple disk accesses (your disk is having to > seek for each file). As others have pointed out, a two pass technique. > based on extension and then sniffing is also a bad idea since icons, etc > would change in the case of a discrepancy. It is not clear that 3 is a problem. It is only probable that 3 may be an issue on a certain machine with a certain configuration. I guarantee that the sniffing is not the bottleneck. Running it through a profiler will be much more worthwhile than sending mail to a list saying "it's slow." And yes, I am the one that suggested profiling. The disk i/o is most certainly not the bottleneck. Given the speed of hard disks today, seek time is not an issue. Even if it took the 12ms maximum seek time on a newer model hard disk, and you were loading a directory with 1000 files in it, that is only 12 seconds. Given the size of cache on newer hard disks, and the fact that people generally open up the same few folders, rather than opening / and traversing the tree looking for things, or opening odd folders randomly, I would guess that the maximum seek time would be around 3-4 milliseconds. It is much more likely some other problem that is specific to something Nautilus is doing to display the list of files. I also suggested other things than profiling, such as writing specific benchmarks to compare test-mime from gnome-vfs and file, which would be much more useful than saying "Nautilus must be slow because echo * is instantaneous" or other such nonsense. Real benchmarks are much more reliable than "it seemed slow" or "I used a stopwatch", as human error and perception can misinterpret how long it actually took to do something. > Sniffing is slow because it opens every file and reads some of it every > time you open a given directory. If you want to make this fast, cache > filetypes; now opening the huge mp3 folder is just a matter of reading a > single cache file and sniffing those files with a modification time > later than that of the cache file. Naturally this would only need to be > done for those really huge directories, it would probably be a waste for > directories with only a hundred files or fewer. Sniffing is not slow because it opens every file and reads some of it. Though, it may be if you end up opening network mounts, since all of the stat()s are network-bound, which is much slower than local hard disk access. There can surely be improvements in speed for network-bound i/o in gnome-vfs, and improvements in file type detection as well, since most all web server installations on the Internet, are broken. They also generally use filename extensions to determine what to send for the Content-Type: header. This is what gnome-vfs uses currently. > I don't think we need to worry about which approach is ultimately going > to perform faster. For a program like Nautilus either there is or is not > a human-noticeable lag time; improving performance when there is no lag > time is totally pointless. Aye. In general, the speed issues have nothing to do with the way the mime type is detected. Any claims that one is substantially faster than the other, is generally due to misperception. The real issues seem to generally be at a lower level, or totally unrelated, such as the issues with some of the thumbnailers. > A number of people have used Windows as an example of why we don't need > to sniff files; though there are a number of features in Windows worth > copying this is definitely not one of them. I have worked on some > commercial software and the number one frivolous bug report or unfixable > user issue occurs when the user attempts to open a file that has an > incorrect filename extension. People on this list have suggested that > this is a user problem not a software problem (i.e. that the user was > stupid and beyond help), but I can assure you that however obvious the > connection between the hidden Windows filename extension and the error > message that our program gave is to me and you, it was not obvious to a > large number of otherwise very intelligent people who just weren't as > knowledgeable about computers. People always think that the icon for a > file is somehow part of the file (it makes sense if you don't think > about it too hard), and so if a file has, say, a jpeg icon it doesn't > occur to them that it is not a jpeg. Indeed. -- dobey From david@davemalcolm.demon.co.uk Sun Jan 4 19:21:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by mail.gnome.org (Postfix) with ESMTP id 89DF618497; Sun, 4 Jan 2004 19:21:39 -0500 (EST) Received: from davemalcolm.demon.co.uk ([80.177.172.172] helo=[192.168.0.3]) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1AdIV0-000C9Z-0Y; Mon, 05 Jan 2004 00:21:38 +0000 Subject: Re: Suggestion for file type detection approach From: Dave Malcolm To: Yves Dionne Cc: Gnome VFS List , Nautilus List , gnome-list@gnome.org, "gnome-devel-list@gnome.org" In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1073262381.32307.3969.camel@shirehorse1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Jan 2004 00:26:22 +0000 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sat, 2004-01-03 at 00:57, Yves Dionne wrote: > On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > > > Why not support recording the mime-type of a file as meta-data (EA) on > > > filesystems that support it (every one of them at this point?). It > > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > > to clearly be the right way to do it. If GNOME VFS supported it then > > > it seems it would be easy to implement for alot of applications. > > > > > > > I agree with you, but while we must provide a quick solution, EA (and > > the attributes themselves) must be standardized cross-unix and > > cross-desktop. This will take some time to mature, since the mechanisms > > for sending files through the Internet (between computers, in general) > > must mature to support EA. I never used Apple operating systems, but it > > looks like they have such a mechanism. Nothing that a tar with EA > > support could not do. > > > > GNOME must provide room today to support state-of-the-art technologies > > in the future, but must at the same time provide solutions to today's > > users using today's technologies. > > > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > > > Indeed, but it's all we have for now. Now = 2.6. > > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". I think this is a great idea - in particular it gives users something they can adjust if the sniffing gets it wrong. If EAs aren't available, perhaps such "sniff overrides" could be stored using the Nautilus metadata system? Though that would make things even slower. > > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. > > It works only for local files. If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. > > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. From bugtraq@gs2.com.br Mon Jan 5 07:27:19 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from zeus.intra.gs2.com.br (unknown [200.165.137.90]) by mail.gnome.org (Postfix) with ESMTP id 3759218667 for ; Mon, 5 Jan 2004 07:27:17 -0500 (EST) Received: from hermes.intra.gs2.com.br (hermes.intra.gs2.com.br [192.168.1.1]) by zeus.intra.gs2.com.br (Postfix) with ESMTP id 245F0302D1; Mon, 5 Jan 2004 09:33:37 -0300 (BRT) Subject: Re: Suggestion for file type detection approach From: Fabio Gomes To: Rodney Dawes Cc: ejk@ucsc.edu, gnome-vfs-list@gnome.org In-Reply-To: <1073238454.26541.173.camel@blackbox.boston.ximian.com> References: <1073083582.3530.77.camel@whipple> <1073238454.26541.173.camel@blackbox.boston.ximian.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1073305961.1035.25.camel@hermes.intra.gs2.com.br> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 09:32:42 -0300 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Em Dom, 2004-01-04 às 14:47, Rodney Dawes escreveu: > On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > > >Given the performance bottleneck imposed by sniffing, I suggest that it > > >is not used anymore in directory listing routines. It should be used > > >when the user tries to open an unknown file. Let's imagine this case: > > > > I don't think this is a good way of thinking about things. The questions are: > > 1. Is sniffing a good idea? > > 2. If so does it work correctly? > > 3. If (1) and (2), is it performing fast enough? > > > > I think others have argued persuasively that sniffing is a good idea > > since unix doesn't generally give file name suffixes to files (even > > though gnome does), and often files have incorrect suffixes. > > > > A number of people have said that there are instances where sniffing is > > not correctly determining the file type. If true, this is an excellent > > argument for fixing those cases, but not at all an argument for throwing > > away sniffing altogether. > > I've only seen one person say that. And as I understand, no real > information was provided. Only a comment of "it broke on this one file." > But yes, it is a good argument for improving the system, not removing > the core functionality. > > > >From your benchmarking it is clear that (3) is a problem, and sniffing > > is taking too long. This is not an argument for getting rid of it > > though, just an argument for speeding it up. Someone suggested running > > it through a profiler, but I doubt that will be worthwhile--the problem > > is almost certainly the multiple disk accesses (your disk is having to > > seek for each file). As others have pointed out, a two pass technique. > > based on extension and then sniffing is also a bad idea since icons, etc > > would change in the case of a discrepancy. > > It is not clear that 3 is a problem. It is only probable that 3 may be > an issue on a certain machine with a certain configuration. I guarantee > that the sniffing is not the bottleneck. Running it through a profiler > will be much more worthwhile than sending mail to a list saying "it's > slow." And yes, I am the one that suggested profiling. The disk i/o is > most certainly not the bottleneck. Given the speed of hard disks today, > seek time is not an issue. Even if it took the 12ms maximum seek time on > a newer model hard disk, and you were loading a directory with 1000 > files in it, that is only 12 seconds. Given the size of cache on newer > hard disks, and the fact that people generally open up the same few > folders, rather than opening / and traversing the tree looking for > things, or opening odd folders randomly, I would guess that the maximum > seek time would be around 3-4 milliseconds. It is much more likely some > other problem that is specific to something Nautilus is doing to display > the list of files. I also suggested other things than profiling, such > as writing specific benchmarks to compare test-mime from gnome-vfs and > file, which would be much more useful than saying "Nautilus must be slow > because echo * is instantaneous" or other such nonsense. Real benchmarks > are much more reliable than "it seemed slow" or "I used a stopwatch", as > human error and perception can misinterpret how long it actually took to > do something. "ONLY" 12 seconds? Is that acceptable for a directory with 1000 files? Can a human error of perception misinterpret the distance between <1s and 20s multiple times with the help of a stopwatch? You must be kidding. :-P > Aye. In general, the speed issues have nothing to do with the way the > mime type is detected. Any claims that one is substantially faster than > the other, is generally due to misperception. The real issues seem to > generally be at a lower level, or totally unrelated, such as the issues > with some of the thumbnailers. Test it by yourself: http://mail.gnome.org/archives/gnome-devel-list/2004-January/msg00010.html If your results confirm my "misperception", I'll blindly agree with everything that you say. :-) I'm not advocating the removal of functionality. People have already pointed how to fix the performance and misidentification issues in efficient manners. What I am trying to do is show the non-believers where the performance problem actually is. Best regards, -- Fabio Gomes de Souza (+55 81 9127-0597) .- GS2 TECNOLOGIA DA INFORMACAO LTDA :: www.gs2.com.br |- IT Infrastructure :: Security :: Embedded systems :: Linux `- Olinda, Brazil - +55 81 3492-7777 - negocios@gs2.com.br From gkarabin@pobox.com Sat Jan 17 20:36:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id B3AD81820C; Sat, 17 Jan 2004 20:36:20 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0I1aHqG013829; Sat, 17 Jan 2004 17:36:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: federico@gnu.org From: George Karabin Subject: tiff multi-document files Date: Sat, 17 Jan 2004 17:36:16 -0800 To: eog-list@gnome.org, gnome-vfs-list@gnome.org X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Scanning and fax applications sometimes store multiple images in a single image/tiff file. I'd like to modify eog to display multi-image tiff files as a flat collection of files, as if it were a directory. Right now it's ignoring the other images in the file. I want to add a gnome-vfs module to map libtiff's directory feature to a gnome-vfs URI with archive-file-format-like methods. For each image file it opens, eog would test to see if it's image/tiff, and then try to open the directory. If the module's installed, then it'll get a directory handle and create the collection. Does the idea sound OK in principle for eog? I'm not sure how much eog wants to know about file-format-specific stuff like this, so I'm asking up-front. I don't think it makes sense to handle these sorts of files in gdk - this doesn't really map well to the animation interface, and there wouldn't be enough developers using it to justify changing APIs. So if this is done, eog has to learn about this tiff idiosyncrasy. Likewise, does this sound OK for gnome-vfs? I think there's less controversy here, but this is a fairly obscure use case. I can't imagine too many apps actually caring to use this, so I hope it's not considered bloat and a bad dependency. - George From jens@triq.net Sun Jan 18 05:19:55 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail4.ewetel.de (mail4-141.ewetel.de [212.6.122.141]) by mail.gnome.org (Postfix) with ESMTP id 4208118212; Sun, 18 Jan 2004 05:19:55 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-74-180.ewetel.net [80.228.74.180]) by mail4.ewetel.de (8.12.1/8.12.9) with ESMTP id i0IAJqHB026433; Sun, 18 Jan 2004 11:19:53 +0100 (MET) Date: Sun, 18 Jan 2004 11:34:27 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org Subject: Re: tiff multi-document files In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi George, On Sat, 17 Jan 2004, George Karabin wrote: > I want to add a gnome-vfs module to map libtiff's directory feature to > a gnome-vfs URI with archive-file-format-like methods. For each image > file it opens, eog would test to see if it's image/tiff, and then try > to open the directory. If the module's installed, then it'll get a > directory handle and create the collection. Nice. > Does the idea sound OK in principle for eog? I'm not sure how much eog > wants to know about file-format-specific stuff like this, so I'm asking > up-front. I don't think it makes sense to handle these sorts of files > in gdk - this doesn't really map well to the animation interface, and > there wouldn't be enough developers using it to justify changing APIs. > So if this is done, eog has to learn about this tiff idiosyncrasy. > > Likewise, does this sound OK for gnome-vfs? I think there's less > controversy here, but this is a fairly obscure use case. I can't > imagine too many apps actually caring to use this, so I hope it's not > considered bloat and a bad dependency. Actually, I think it should be possible to write a gnome-vfs module, which adds a new URI scheme and handles such tiff files properly. If it behaves like a directory from the gnome-vfs client point of view, eog will automatically use the collection view for this then. I am not very familar with 3rd party gnome-vfs modules, but AFAICS you neither need to touch gnome-vfs nor eog to get this working. Regards, Jens From alexl@redhat.com Mon Jan 19 04:39:29 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 2721E180EB; Mon, 19 Jan 2004 04:39:29 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNl31117; Mon, 19 Jan 2004 04:39:23 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNa09346; Mon, 19 Jan 2004 04:39:23 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0J9d1cG019229; Mon, 19 Jan 2004 04:39:02 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: Jens Finke Cc: George Karabin , eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 19 Jan 2004 10:39:21 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > > Does the idea sound OK in principle for eog? I'm not sure how much eog > > wants to know about file-format-specific stuff like this, so I'm asking > > up-front. I don't think it makes sense to handle these sorts of files > > in gdk - this doesn't really map well to the animation interface, and > > there wouldn't be enough developers using it to justify changing APIs. > > So if this is done, eog has to learn about this tiff idiosyncrasy. > > > > Likewise, does this sound OK for gnome-vfs? I think there's less > > controversy here, but this is a fairly obscure use case. I can't > > imagine too many apps actually caring to use this, so I hope it's not > > considered bloat and a bad dependency. > > Actually, I think it should be possible to write a gnome-vfs module, which > adds a new URI scheme and handles such tiff files properly. If it behaves > like a directory from the gnome-vfs client point of view, eog will > automatically use the collection view for this then. This is called "chained uris", and gnome-vfs has some code for it. However, at the moment it just doesn't work. My hope is that eventually we'll get it fixed though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded vegetarian card sharp with a robot buddy named Sparky. She's a mistrustful paranoid cab driver with her own daytime radio talk show. They fight crime! From gkarabin@pobox.com Mon Jan 19 16:49:06 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from util.ext.ti.com (util.ext.ti.com [192.91.75.135]) by mail.gnome.org (Postfix) with ESMTP id 15A5D180FE for ; Mon, 19 Jan 2004 16:49:06 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by util.ext.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn55O004430 for ; Mon, 19 Jan 2004 15:49:05 -0600 (CST) Received: from sdca.asp.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn4rj024363 for ; Mon, 19 Jan 2004 15:49:04 -0600 (CST) Received: from [146.252.133.9] (HELO pobox.com) by sdca.asp.ti.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 3657067 for gnome-vfs-list@gnome.org; Mon, 19 Jan 2004 13:59:43 -0800 Message-ID: <400C50D0.3090701@pobox.com> Date: Mon, 19 Jan 2004 13:49:04 -0800 From: George J Karabin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gnome-vfs-list@gnome.org Subject: [patch] tar method won't open root directory of archive Content-Type: multipart/mixed; boundary="------------060702050303070000000102" Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------060702050303070000000102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I haven't seen any documentation in gnome-vfs to indicate how one should encode the root directory of an archive into a URI, but empirically, it looks like something like either "foo.tar#tar:" or "foo.tar#tar:/" should work (gnome-vfs expands the former to the latter before giving the uri to the module's method). The tar method doesn't handle either of these cases. The attached patch fixes this. Try out something like "gnomevfs-ls /path-to-file/foo.tar#:" before and after the patch as a test case. No CVS access for me - can someone apply it if it passes review? The problem's filed in bugzilla as well: http://bugzilla.gnome.org/show_bug.cgi?id=131959 - George --------------060702050303070000000102 Content-Type: text/plain; name="gnome-vfs-2.4.1-handle-root.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gnome-vfs-2.4.1-handle-root.patch" --- gnome-vfs-2.4.1/modules/tar-method.c.handle-root 2002-05-12 20:38:29.000000000 -0700 +++ gnome-vfs-2.4.1/modules/tar-method.c 2004-01-19 12:43:14.000000000 -0800 @@ -51,6 +51,7 @@ int current_index; gchar *filename; gboolean is_directory; + gboolean is_root; } FileHandle; #define TARPET_BLOCKSIZE (sizeof (union TARPET_block)) @@ -154,35 +155,42 @@ return ret; } -static GNode* -tree_lookup_entry (const GNode *tree, const gchar *name) +static gboolean +tree_lookup_entry (const GNode *tree, const gchar *name, GNode **node) { - GNode *ret; char *root = g_strdup (name); char *txt = root; - - if (txt[0] == '/') - txt++; - ret = real_lookup_entry (tree, txt, 1); - if (!ret && txt[strlen (txt) - 1] != '/') + if (txt[0] == '/') + { + if (txt[1] == '\0') + { + g_free (root); + return TRUE; + } + else + txt++; + } + + *node = real_lookup_entry (tree, txt, 1); + if (!*node && txt[strlen (txt) - 1] != '/') { txt = g_strconcat (txt, "/", NULL); g_free (root); root = txt; - ret = real_lookup_entry (tree, txt, 1); + *node = real_lookup_entry (tree, txt, 1); } g_free (root); - if (ret && ret != tree->children) + if (*node && *node != tree->children) { - union TARPET_block *b = ret->data; + union TARPET_block *b = (*node)->data; b--; if (b->p.typeflag == TARPET_TYPE_LONGFILEN) - ret = ret->next; + *node = (*node)->next; } - return ret; + return FALSE; } static TarFile* read_tar_file (GnomeVFSHandle *handle) @@ -228,7 +236,7 @@ } split_name (ret->blocks[i].p.name, &dir, &rest); - node = tree_lookup_entry (ret->info_tree, dir); + tree_lookup_entry (ret->info_tree, dir, &node); if (!node) { @@ -322,7 +330,7 @@ tar = ensure_tarfile (uri); if (!tar) return GNOME_VFS_ERROR_BAD_FILE; - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); if (!node) { tar_file_unref (tar); @@ -468,13 +476,17 @@ union TARPET_block *start, *current; GNode *node; int i; + gboolean is_root; if (!uri->parent) return GNOME_VFS_ERROR_INVALID_URI; tar = ensure_tarfile (uri); if (uri->text) { - node = tree_lookup_entry (tar->info_tree, uri->text); + is_root = tree_lookup_entry (tar->info_tree, uri->text, &node); + } + if (!is_root) + { if (!node) { tar_file_unref (tar); @@ -490,8 +502,11 @@ else current = NULL; } - else + if (is_root || !uri->text) { + /* FIXME: gnome-vfs never seems to generate !uri->text + condition. Is it permissible by contract? */ + node = tar->info_tree; if (!node) { @@ -516,6 +531,7 @@ break; new_handle->current_index = i; new_handle->is_directory = TRUE; + new_handle->is_root = is_root; *method_handle = (GnomeVFSMethodHandle*) new_handle; @@ -550,7 +566,7 @@ int i; if (uri->text) - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); else node = tar->info_tree->children; @@ -635,15 +651,16 @@ GnomeVFSURI *uri; gchar *str; GNode *node; - + gboolean is_root; + if (!handle->current) return GNOME_VFS_ERROR_EOF; str = g_strconcat (handle->filename, "#tar:", handle->current->p.name, NULL); uri = gnome_vfs_uri_new (str); do_get_file_info (method, uri, file_info, 0, context); - node = tree_lookup_entry (handle->tar->info_tree, uri->text); - if (!node) + is_root = tree_lookup_entry (handle->tar->info_tree, uri->text, &node); + if (!node && !is_root) { gnome_vfs_uri_unref (uri); return GNOME_VFS_ERROR_NOT_FOUND; --------------060702050303070000000102-- From cbhoh@yahoo.com Tue Jan 20 01:36:27 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60307.mail.yahoo.com (web60307.mail.yahoo.com [216.109.118.118]) by mail.gnome.org (Postfix) with SMTP id 58F7518675 for ; Tue, 20 Jan 2004 01:36:27 -0500 (EST) Message-ID: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Received: from [161.142.100.80] by web60307.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 22:36:27 PST Date: Mon, 19 Jan 2004 22:36:27 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: gnome_vfs_get_mime_type does NOT get the mime_type To: gnome-vfs-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi guys, I need some help here, today I just use jhbuild to rebuild the 2.5 gnome. I noticed that the gnome_vfs_get_mime_type or gnome_vfs_get_mime_type_from_uri does not work. since the latest yelp use the gnome-vfs to determine the correct mimetype and then respond to the help file according to mime-type. For whatever file I use gnome_vfs_get_mime_type to retrive, I keep getting application/octect-stream. Is there anything i miss out about ? HOH ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Tue Jan 20 02:17:30 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id 9E92818136; Tue, 20 Jan 2004 02:17:29 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0K7HPqG014225; Mon, 19 Jan 2004 23:17:25 -0800 (PST) In-Reply-To: <1074505161.2413.109.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Mon, 19 Jan 2004 23:17:26 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: >> Actually, I think it should be possible to write a gnome-vfs module, >> which >> adds a new URI scheme and handles such tiff files properly. If it >> behaves >> like a directory from the gnome-vfs client point of view, eog will >> automatically use the collection view for this then. > > This is called "chained uris", and gnome-vfs has some code for it. > However, at the moment it just doesn't work. My hope is that eventually > we'll get it fixed though. I looked at the archives for this list on chaining and the shared vfs ideas on xdg-list. Has anything come of your idea for a common VFS URI spec: https://listman.redhat.com/archives/xdg-list/2003-September/ msg00110.html ? Do you think it makes any sense to attempt to fix chaining before attempting such a spec? Regarding a VFS URI spec, I thought I'd go looking for relevant internet standards and drafts, and note them here. They might make for some good references for requirements gathering for anyone thinking about such a spec. Anyway, RFC 2396 provides a general BNF for URIs that seems workable[1]. RFC 2396bis was in the running to succeed it, but expired in December. It had expanded on encoding and escaping guidelines, which 2396 was really vague on, but basically left the specifics for URI components to TBD docs that describe those URIs. I.e., no conclusive help here anytime soon. I don't know why it lost momentum, and am not sure if there's any sense trying to salvage some of its ideas or not. Maybe it makes sense to get URIs that VFS projects care about into ietf drafts? Looks to be a slow-moving standards body - dunno if it's worth the effort or not - I don't have any experience with standards bodies. RFC 1738 provides rules for some specific URI types. RFC1738bis is an update based on 2396bis, so it's left hanging as well. The ssh URI draft that Jeff Waugh referred to some time back is based on other drafts that are based on the expired 2396bis, so it seems likely that it'll expire as well unless 239bis picks up again. Interesting RFCs: ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt ftp://ftp.rfc-editor.org/in-notes/rfc2079.txt ftp://ftp.rfc-editor.org/in-notes/rfc2483.txt ftp://ftp.rfc-editor.org/in-notes/rfc2168.txt Other relevant/interesting drafts: http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri- rfc2396bis-03.txt (expired) http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-06.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri -01.txt - George [1] It's old enough that for all I know gnome-vfs or kio could be based on it. I have no idea if that's the case or not. From alexl@redhat.com Tue Jan 20 03:00:52 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9DB8618958; Tue, 20 Jan 2004 03:00:52 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80ql14111; Tue, 20 Jan 2004 03:00:52 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80qa30628; Tue, 20 Jan 2004 03:00:52 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0K80UcG000940; Tue, 20 Jan 2004 03:00:31 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040120063627.8391.qmail@web60307.mail.yahoo.com> References: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074585650.2413.185.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 20 Jan 2004 09:00:51 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 07:36, Chee Bin HOH wrote: > Hi guys, > > I need some help here, today I just use jhbuild to > rebuild the 2.5 gnome. I noticed that the > gnome_vfs_get_mime_type or > gnome_vfs_get_mime_type_from_uri does not work. > > since the latest yelp use the gnome-vfs to determine > the correct mimetype and then respond to the help file > according to mime-type. > > For whatever file I use gnome_vfs_get_mime_type to > retrive, I keep getting application/octect-stream. > > Is there anything i miss out about ? Did you install shared-mime-info? Did you set XDG_DATA_DIRS to include $prefix/share? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a globe-trotting skateboarding hairdresser who dotes on his loving old ma. She's a foxy cat-loving barmaid with an incredible destiny. They fight crime! From cbhoh@yahoo.com Wed Jan 21 01:47:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60309.mail.yahoo.com (web60309.mail.yahoo.com [216.109.118.120]) by mail.gnome.org (Postfix) with SMTP id 59D2718254 for ; Wed, 21 Jan 2004 01:47:13 -0500 (EST) Message-ID: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Received: from [161.142.195.153] by web60309.mail.yahoo.com via HTTP; Tue, 20 Jan 2004 21:20:17 PST Date: Tue, 20 Jan 2004 21:20:17 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074585650.2413.185.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --- Alexander Larsson wrote: > Did you install shared-mime-info? Did you set > XDG_DATA_DIRS to include > $prefix/share? I did install share-mime-info from cvs.freedesktop.org (as requested by jhbuild), but I did not set the env XDG_DATA_DIRS. I need to set XDG_DATA_DIRS while I build share-mime-info or others? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a globe-trotting skateboarding hairdresser who > dotes on his loving old > ma. She's a foxy cat-loving barmaid with an > incredible destiny. They fight > crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From alexl@redhat.com Wed Jan 21 05:27:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9AF4B181E9; Wed, 21 Jan 2004 05:27:50 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARol29294; Wed, 21 Jan 2004 05:27:50 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARoa13682; Wed, 21 Jan 2004 05:27:50 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LARScG018691; Wed, 21 Jan 2004 05:27:28 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040121052017.24059.qmail@web60309.mail.yahoo.com> References: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074680868.2413.359.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:49 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > --- Alexander Larsson wrote: > > Did you install shared-mime-info? Did you set > > XDG_DATA_DIRS to include > > $prefix/share? > > I did install share-mime-info from cvs.freedesktop.org > (as requested by jhbuild), but I did not set the env > XDG_DATA_DIRS. > > I need to set XDG_DATA_DIRS while I build > share-mime-info or others? No, not while building. You need to set it when running apps. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a genetically engineered vegetarian inventor with a winning smile and a way with the ladies. She's a beautiful nymphomaniac research scientist on the trail of a serial killer. They fight crime! From alexl@redhat.com Wed Jan 21 05:27:13 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 37B74181E9; Wed, 21 Jan 2004 05:27:13 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBl29170; Wed, 21 Jan 2004 05:27:11 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBa13574; Wed, 21 Jan 2004 05:27:11 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LAQmcG018568; Wed, 21 Jan 2004 05:26:49 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org In-Reply-To: References: <1074505161.2413.109.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:09 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 08:17, George Karabin wrote: > On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > > > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > >> Actually, I think it should be possible to write a gnome-vfs module, > >> which > >> adds a new URI scheme and handles such tiff files properly. If it > >> behaves > >> like a directory from the gnome-vfs client point of view, eog will > >> automatically use the collection view for this then. > > > > This is called "chained uris", and gnome-vfs has some code for it. > > However, at the moment it just doesn't work. My hope is that eventually > > we'll get it fixed though. > > > I looked at the archives for this list on chaining and the shared vfs > ideas on xdg-list. Has anything come of your idea for a common VFS URI > spec: > https://listman.redhat.com/archives/xdg-list/2003-September/ > msg00110.html ? Do you think it makes any sense to attempt to fix > chaining before attempting such a spec? There hasn't been any work on it that I know of. And in such a spec it would be nice if chaining was supported. > Regarding a VFS URI spec, I thought I'd go looking for relevant > internet standards and drafts, and note them here. They might make for > some good references for requirements gathering for anyone thinking > about such a spec. In some sense its sort of unfortunate that gnome-vfs uris are based on normal URIs, because that limits us a bit and in some cases it causes trouble because people expect that gnome-vfs should support all sorts of things you can do with web-uris, such as mailto:, callto:, javascript: etc. In fact, we partially handle these by installing handler app settings for them, but in reality they are not really gnome-vfs uris. The way gnome-vfs currently handles chained uris is described in gnome-vfs/doc/uri.txt. Its working to some extent, but the work has never really been finalized and polished up to work in the desktop. To make it work you'd have to: * Work on the chained methods (zip, tar, gzip etc) to make them work better than they do today. The existance of the gnome-vfs daemon in 2.5 should make this easier * Finish the work with putting chained uri handlers into the mime info, so that the file manager can now what file types are chainable * Make the file handler recognize chainable file types and browse them * Make all users of gnome-vfs correctly handle chained uris (i.e. gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns file:///some/file.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an old-fashioned day-dreaming Green Beret possessed of the uncanny powers of an insect. She's a cold-hearted antique-collecting hooker married to the Mob. They fight crime! From cbhoh@yahoo.com Wed Jan 21 06:22:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60306.mail.yahoo.com (web60306.mail.yahoo.com [216.109.118.117]) by mail.gnome.org (Postfix) with SMTP id 9AC8718422 for ; Wed, 21 Jan 2004 06:22:51 -0500 (EST) Message-ID: <20040121112245.44069.qmail@web60306.mail.yahoo.com> Received: from [161.142.195.41] by web60306.mail.yahoo.com via HTTP; Wed, 21 Jan 2004 03:22:45 PST Date: Wed, 21 Jan 2004 03:22:45 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074680868.2413.359.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hey, it works. ;) Thank! --- Alexander Larsson wrote: > On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > > --- Alexander Larsson wrote: > > > Did you install shared-mime-info? Did you set > > > XDG_DATA_DIRS to include > > > $prefix/share? > > > > I did install share-mime-info from > cvs.freedesktop.org > > (as requested by jhbuild), but I did not set the > env > > XDG_DATA_DIRS. > > > > I need to set XDG_DATA_DIRS while I build > > share-mime-info or others? > > No, not while building. You need to set it when > running apps. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a genetically engineered vegetarian inventor > with a winning smile and a > way with the ladies. She's a beautiful nymphomaniac > research scientist on the > trail of a serial killer. They fight crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Sat Jan 24 00:53:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-03-eri0.socal.rr.com (ms-smtp-03-qfe0.socal.rr.com [66.75.162.135]) by mail.gnome.org (Postfix) with ESMTP id 73D0A182A2; Sat, 24 Jan 2004 00:53:14 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-03-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0O5rAF3022083; Fri, 23 Jan 2004 21:53:11 -0800 (PST) In-Reply-To: <1074680829.2413.357.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9618B740-4E31-11D8-B6FD-000A95A6935E@pobox.com> Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Fri, 23 Jan 2004 21:53:08 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 21, 2004, at 2:27 AM, Alexander Larsson wrote: > In some sense its sort of unfortunate that gnome-vfs uris are based on > normal URIs, because that limits us a bit and in some cases it causes > trouble because people expect that gnome-vfs should support all sorts > of > things you can do with web-uris, such as mailto:, callto:, javascript: > etc. In fact, we partially handle these by installing handler app > settings for them, but in reality they are not really gnome-vfs uris. Regarding the IETF docs, the thing I'm most interested in is to be sure that the grammar that they publish for URIs are the same as what gnome-vfs uses, so that URIs that are appropriate to the VFS can be generated from some external source, and be handled by a gnome-vfs client that doesn't necessarily know it's content. > The way gnome-vfs currently handles chained uris is described in > gnome-vfs/doc/uri.txt. Its working to some extent, but the work has > never really been finalized and polished up to work in the desktop. > Thanks - the text files aren't in the release tarballs. Looking at them in cvs helps out a lot. > To make it work you'd have to: > * Work on the chained methods (zip, tar, gzip etc) to make them work > better than they do today. The existance of the gnome-vfs daemon in 2.5 > should make this easier > * Finish the work with putting chained uri handlers into the mime info, > so that the file manager can now what file types are chainable > * Make the file handler recognize chainable file types and browse them > * Make all users of gnome-vfs correctly handle chained uris (i.e. > gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns > file:///some/file.) Thanks for the laundry list - I can start working toward these. I'll be away from email for a few days, but I'll be working my way through the new code over the course of the week. - George From thomas.cataldo@aliacom.fr Sun Jan 25 09:14:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0902.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 36753187E9 for ; Sun, 25 Jan 2004 09:14:21 -0500 (EST) Received: from localhost (AToulouse-206-1-16-219.w81-50.abo.wanadoo.fr [81.50.219.219]) by mwinf0902.wanadoo.fr (SMTP Server) with ESMTP id 8F0FD18000CC for ; Sun, 25 Jan 2004 15:14:19 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 0A33410712E for ; Sun, 25 Jan 2004 15:09:12 +0100 (CET) Subject: [PATCH] nntp method leak fixes From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-P0V5Zy6gc1b7U4iju1UH" Message-Id: <1075039751.12033.9.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 25 Jan 2004 15:09:12 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-P0V5Zy6gc1b7U4iju1UH Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Here is a patch to fix a few leaks in the nntp method. I tested it using gnomevfs-ls nntp:///alt.binaries.anime regards, Thomas. --=-P0V5Zy6gc1b7U4iju1UH Content-Disposition: attachment; filename=nntp-method-leaks.diff Content-Type: text/x-patch; name=nntp-method-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1715 diff -u -r1.1715 ChangeLog --- ChangeLog 23 Jan 2004 09:59:44 -0000 1.1715 +++ ChangeLog 25 Jan 2004 13:58:56 -0000 @@ -1,3 +1,8 @@ +2004-01-25 Thomas Cataldo + + * modules/nntp-method.c: (parse_date_string), (parse_header): some + memory leak fixes. + 2004-01-23 Alexander Larsson * schemas/Makefile.am: Index: modules/nntp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/nntp-method.c,v retrieving revision 1.5 diff -u -r1.5 nntp-method.c --- modules/nntp-method.c 16 Jun 2002 23:43:35 -0000 1.5 +++ modules/nntp-method.c 25 Jan 2004 13:58:57 -0000 @@ -814,6 +814,12 @@ g_message("error parsing %s, %s", date_string, temp_str); } + if (filename != NULL) { + g_free (filename); + } + if (linkname != NULL) { + g_free (linkname); + } g_free(temp_str); *t = s.st_mtime; @@ -904,6 +910,8 @@ file_start = strrchr (temp_str, '-'); if (file_start == NULL) { + g_free (*message_id); + g_free (temp_str); return FALSE; } --=-P0V5Zy6gc1b7U4iju1UH-- From cbhoh@mimos.my Wed Jan 28 05:45:42 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Jan 2004 18:39:13 +0800 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH From thomas.cataldo@aliacom.fr Thu Jan 29 21:06:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0904.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 32FD318B2C for ; Thu, 29 Jan 2004 21:06:53 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0904.wanadoo.fr (SMTP Server) with ESMTP id 951C0180012A for ; Fri, 30 Jan 2004 03:06:49 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 82288106FD4 for ; Fri, 30 Jan 2004 03:00:53 +0100 (CET) Subject: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-vEputk1gGiSFtfo2JnkO" Message-Id: <1075428053.15247.11.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 03:00:53 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-vEputk1gGiSFtfo2JnkO Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests agains ftp and http urls. By the way, as my previous patch against the nntp method was not reviewed, could you tell me if this list is the right place to send patches, or if a bug report is a better way. cheers, Thomas. --=-vEputk1gGiSFtfo2JnkO Content-Disposition: attachment; filename=vfs-socket-leaks.diff Content-Type: text/x-patch; name=vfs-socket-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1716 diff -u -r1.1716 ChangeLog --- ChangeLog 27 Jan 2004 18:59:08 -0000 1.1716 +++ ChangeLog 30 Jan 2004 01:55:40 -0000 @@ -1,3 +1,12 @@ +2004-01-30 Thomas Cataldo + + plug some gnome_vfs_socket leaks. + + * libgnomevfs/gnome-vfs-socket-buffer.c: + (gnome_vfs_socket_buffer_destroy): + * modules/ftp-method.c: (do_transfer_command), (end_transfer), + (ftp_connection_create), (ftp_connection_destroy): + 2004-01-27 David Hawthorne * daemon/gnome-vfs-daemon.c Index: libgnomevfs/gnome-vfs-socket-buffer.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/libgnomevfs/gnome-vfs-socket-buffer.c,v retrieving revision 1.8 diff -u -r1.8 gnome-vfs-socket-buffer.c --- libgnomevfs/gnome-vfs-socket-buffer.c 15 Jan 2004 09:55:51 -0000 1.8 +++ libgnomevfs/gnome-vfs-socket-buffer.c 30 Jan 2004 01:55:41 -0000 @@ -104,6 +104,7 @@ if (close_socket) { gnome_vfs_socket_close (socket_buffer->socket); + g_free(socket_buffer->socket); } g_free (socket_buffer); return GNOME_VFS_OK; Index: modules/ftp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/ftp-method.c,v retrieving revision 1.96 diff -u -r1.96 ftp-method.c --- modules/ftp-method.c 22 Jan 2004 12:29:10 -0000 1.96 +++ modules/ftp-method.c 30 Jan 2004 01:55:44 -0000 @@ -62,14 +62,12 @@ typedef struct { GnomeVFSMethodHandle method_handle; - GnomeVFSInetConnection *inet_connection; GnomeVFSSocketBuffer *socket_buf; GnomeVFSURI *uri; gchar *cwd; GString *response_buffer; gchar *response_message; gint response_code; - GnomeVFSInetConnection *data_connection; GnomeVFSSocketBuffer *data_socketbuf; GnomeVFSFileOffset offset; enum { @@ -384,6 +382,7 @@ char *host = NULL; gint port; GnomeVFSResult result; + GnomeVFSInetConnection *data_connection; GnomeVFSSocket *socket; /* Image mode (binary to the uninitiated) */ @@ -414,7 +413,7 @@ } /* connect */ - result = gnome_vfs_inet_connection_create (&conn->data_connection, + result = gnome_vfs_inet_connection_create (&data_connection, host, port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -424,16 +423,10 @@ return result; } - socket = gnome_vfs_inet_connection_to_socket (conn->data_connection); + socket = gnome_vfs_inet_connection_to_socket (data_connection); conn->data_socketbuf = gnome_vfs_socket_buffer_new (socket); - if (conn->socket_buf == NULL) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - return GNOME_VFS_ERROR_GENERIC; - } - - if (conn->offset) - { + if (conn->offset) { gchar *tmpstring; tmpstring = g_strdup_printf ("REST %Lu", conn->offset); @@ -441,8 +434,7 @@ g_free (tmpstring); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } } @@ -450,16 +442,14 @@ result = do_control_write (conn, command); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } result = get_response (conn); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } @@ -501,15 +491,10 @@ if(conn->data_socketbuf) { gnome_vfs_socket_buffer_flush (conn->data_socketbuf); - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); conn->data_socketbuf = NULL; } - if (conn->data_connection) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - conn->data_connection = NULL; - } - result = get_response (conn); return result; @@ -545,6 +530,7 @@ gint port = control_port; const gchar *user = anon_user; const gchar *pass = anon_pass; + GnomeVFSInetConnection* inet_connection; conn->uri = gnome_vfs_uri_dup (uri); conn->response_buffer = g_string_new (""); @@ -565,7 +551,7 @@ pass = gnome_vfs_uri_get_password (uri); } - result = gnome_vfs_inet_connection_create (&conn->inet_connection, + result = gnome_vfs_inet_connection_create (&inet_connection, gnome_vfs_uri_get_host_name (uri), port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -581,11 +567,11 @@ return result; } - conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (conn->inet_connection); + conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (inet_connection); if (conn->socket_buf == NULL) { g_warning ("Getting socket buffer failed"); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_inet_connection_destroy (inet_connection, NULL); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -612,8 +598,7 @@ /* login failed */ g_warning ("FTP server said: \"%d %s\"\n", conn->response_code, conn->response_message); - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -645,11 +630,8 @@ ftp_connection_destroy (FtpConnection *conn) { - if (conn->inet_connection) - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); - if (conn->socket_buf) - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_free (conn->cwd); @@ -659,11 +641,8 @@ g_free (conn->response_message); g_free (conn->server_type); - if (conn->data_connection) - gnome_vfs_inet_connection_destroy(conn->data_connection, NULL); - if (conn->data_socketbuf) - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); g_free (conn->dirlist); g_free (conn->dirlistptr); --=-vEputk1gGiSFtfo2JnkO-- From alexl@redhat.com Fri Jan 30 03:05:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 42D57182E3 for ; Fri, 30 Jan 2004 03:05:39 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Vb24660; Fri, 30 Jan 2004 03:05:31 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Ua05769; Fri, 30 Jan 2004 03:05:30 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0U853kC017335; Fri, 30 Jan 2004 03:05:04 -0500 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Alexander Larsson To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Message-Id: <1075449929.8585.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 30 Jan 2004 09:05:29 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > Hi, > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > agains ftp and http urls. > > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. Nah, it works. Christophe or I will get to it eventually. I'm just horribly busy with other stuff at the moment. Your first patch is tagged in my inbox and will get attention when i have time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded coffee-fuelled cop from a doomed world. She's a strong-willed thirtysomething Valkyrie descended from a line of powerful witches. They fight crime! From thomas.cataldo@aliacom.fr Fri Jan 30 03:13:22 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0901.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id C0FDC18FF9 for ; Fri, 30 Jan 2004 03:13:10 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0901.wanadoo.fr (SMTP Server) with ESMTP id 8EA02180021B; Fri, 30 Jan 2004 09:13:02 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id D1619106FD4; Fri, 30 Jan 2004 09:07:03 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Alexander Larsson Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075449929.8585.37.camel@localhost.localdomain> References: <1075428053.15247.11.camel@buffy> <1075449929.8585.37.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1075450023.15247.13.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 09:07:03 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 09:05, Alexander Larsson wrote: > On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > > Hi, > > > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > > agains ftp and http urls. > > > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > Nah, it works. Christophe or I will get to it eventually. I'm just > horribly busy with other stuff at the moment. Your first patch is tagged > in my inbox and will get attention when i have time. Ok, thanks for the quick reply. From root@cavtel.net Thu Jan 29 17:38:23 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from xx.mx.cavtel.net (xx.mx.cavtel.net [64.83.1.45]) by mail.gnome.org (Postfix) with ESMTP id 5A15618E5F; Thu, 29 Jan 2004 17:38:23 -0500 (EST) Received: by xx.mx.cavtel.net (Postfix, from userid 0) id CEE681D42C8; Thu, 29 Jan 2004 17:38:22 -0500 (EST) Received: from msg2.cavtel.net (msg2.mx.cavtel.net [64.83.1.144]) by xx.mx.cavtel.net (Postfix) with ESMTP id 96E8A4382D for ; Wed, 28 Jan 2004 06:17:55 -0500 (EST) Received: by msg2.cavtel.net (Postfix, from userid 1002) id B49283139E; Wed, 28 Jan 2004 06:02:41 -0500 (EST) Received: from mail.gnome.org (moniker.gnome.org [67.72.78.218]) by msg2.cavtel.net (Postfix) with ESMTP id 3E3E431B89 for ; Wed, 28 Jan 2004 05:58:12 -0500 (EST) Received: from moniker.gnome.org (moniker.gnome.org [127.0.0.1]) by mail.gnome.org (Postfix) with ESMTP id A8B08184D1; Wed, 28 Jan 2004 05:59:25 -0500 (EST) Delivered-To: desktop-devel-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Content-Transfer-Encoding: 7bit X-BeenThere: desktop-devel-list@gnome.org X-Loop: desktop-devel-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Date: 28 Jan 2004 18:39:13 +0800 X-Bayesian-Class: No, tests=bogofilter, spamicity=0.188133, version=0.15.8 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list From cfergeau@mipsys.com Fri Jan 30 04:11:12 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from bugsbunny.mipsys.com (griffon.mipsys.com [217.167.51.129]) by mail.gnome.org (Postfix) with ESMTP id 1651918A96 for ; Fri, 30 Jan 2004 04:11:12 -0500 (EST) Received: from teuf by bugsbunny.mipsys.com with local (Exim 3.36 #1 (Debian)) id 1AmUfU-0003Nj-00; Fri, 30 Jan 2004 10:10:28 +0100 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Christophe Fergeau To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1075453828.3843.0.camel@bugsbunny.mipsys.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.3 Date: Fri, 30 Jan 2004 10:10:28 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. I prefer having a bug report in addition to mails since I regularly check the pending bugs in bugzilla, and process them as I find time. Christophe From thomas.cataldo@aliacom.fr Fri Jan 30 04:37:20 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail.aliacom.fr (mail.aliacom.fr [213.41.82.82]) by mail.gnome.org (Postfix) with ESMTP id BCDC318FF1; Fri, 30 Jan 2004 04:37:19 -0500 (EST) Received: from chienne.aliacom-local (chienne.aliacom-local [192.168.1.38]) by mail.aliacom.fr (Postfix) with ESMTP id D2AE7202DC; Fri, 30 Jan 2004 10:37:17 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Christophe Fergeau Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075453828.3843.0.camel@bugsbunny.mipsys.com> References: <1075428053.15247.11.camel@buffy> <1075453828.3843.0.camel@bugsbunny.mipsys.com> Content-Type: text/plain Organization: Aliacom Message-Id: <1075455508.14823.17.camel@chienne.aliacom-local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 10:38:28 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 10:10, Christophe Fergeau wrote: > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > I prefer having a bug report in addition to mails since I regularly > check the pending bugs in bugzilla, and process them as I find time. My two patches (nttp and ftp/http leaks) are filed as bugs #132950 and #132951 regards, Thomas. From jitendra.moon@wipro.com Sun Jan 4 04:11:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by mail.gnome.org (Postfix) with ESMTP id 4E185185D5 for ; Sun, 4 Jan 2004 04:11:51 -0500 (EST) Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i049BnOZ025386 for ; Sun, 4 Jan 2004 14:41:49 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Sun, 04 Jan 2004 14:42:58 +0530 Received: from chn-snr-bh3.wipro.com ([10.145.50.93]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from hyd-mdp-msg.wipro.com ([10.150.50.99]) by chn-snr-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from mdpnok109242 ([192.168.142.126]) by hyd-mdp-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Reply-To: From: "Jitendra Moon" To: Date: Sun, 4 Jan 2004 14:46:14 +0530 Message-ID: <000601c3d2a3$67495ff0$b786a8c0@mdpnok109242> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3D2D1.81019BF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 04 Jan 2004 09:11:48.0301 (UTC) FILETIME=[C8450FD0:01C3D2A2] Subject: (no subject) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 I have installed gnome-vfs-2.0 on my debian box. Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs API=92s. Any sample code in this regard will be of great help. =20 Are only gnome vfs libraries sufficient to access above mentioned device file systems on debian Linux? Or do we need to install some thing more on top of gnome VFS? =20 Again any sample code will be of great help. =20 =20 =20 Jitendra Moon =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I have installed gnome-vfs-2.0 on my debian = box.

Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs = API’s.

Any sample code in this regard will be of great = help.

 

Are only gnome vfs libraries sufficient to access = above mentioned device file systems on debian = Linux?

Or do we need to install some thing more on top of = gnome VFS?

 

Again any sample code will be of great = help.

 

 

 

Jitendra Moon

 

 

 

 

 

 

 

 

 

 

 

 

 

------=_NextPart_000_0007_01C3D2D1.81019BF0-- From ejk@ucsc.edu Fri Jan 2 17:47:02 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by mail.gnome.org (Postfix) with ESMTP id EF43B18448; Fri, 2 Jan 2004 17:47:01 -0500 (EST) Received: from [169.233.37.23] (k-d0789.resnet.ucsc.edu [169.233.37.23]) by ucsc.edu (8.10.1/8.10.1) with ESMTP id i02MhLx01991; Fri, 2 Jan 2004 14:43:23 -0800 (PST) Subject: Re: Suggestion for file type detection approach From: Edward Jay Kreps Reply-To: Suggestion.for.file.type.detection.approach@ucsc.edu To: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org, gnome-vfs-list@gnome.org Content-Type: text/plain Message-Id: <1073083582.3530.77.camel@whipple> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 14:46:22 -0800 Content-Transfer-Encoding: 7bit X-UCSC-CATS-MailScanner: Found to be clean X-UCSC-CATS-MailScanner-SpamCheck: Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: >Given the performance bottleneck imposed by sniffing, I suggest that it >is not used anymore in directory listing routines. It should be used >when the user tries to open an unknown file. Let's imagine this case: I don't think this is a good way of thinking about things. The questions are: 1. Is sniffing a good idea? 2. If so does it work correctly? 3. If (1) and (2), is it performing fast enough? I think others have argued persuasively that sniffing is a good idea since unix doesn't generally give file name suffixes to files (even though gnome does), and often files have incorrect suffixes. A number of people have said that there are instances where sniffing is not correctly determining the file type. If true, this is an excellent argument for fixing those cases, but not at all an argument for throwing away sniffing altogether. >From your benchmarking it is clear that (3) is a problem, and sniffing is taking too long. This is not an argument for getting rid of it though, just an argument for speeding it up. Someone suggested running it through a profiler, but I doubt that will be worthwhile--the problem is almost certainly the multiple disk accesses (your disk is having to seek for each file). As others have pointed out, a two pass technique. based on extension and then sniffing is also a bad idea since icons, etc would change in the case of a discrepancy. Sniffing is slow because it opens every file and reads some of it every time you open a given directory. If you want to make this fast, cache filetypes; now opening the huge mp3 folder is just a matter of reading a single cache file and sniffing those files with a modification time later than that of the cache file. Naturally this would only need to be done for those really huge directories, it would probably be a waste for directories with only a hundred files or fewer. I don't think we need to worry about which approach is ultimately going to perform faster. For a program like Nautilus either there is or is not a human-noticeable lag time; improving performance when there is no lag time is totally pointless. A number of people have used Windows as an example of why we don't need to sniff files; though there are a number of features in Windows worth copying this is definitely not one of them. I have worked on some commercial software and the number one frivolous bug report or unfixable user issue occurs when the user attempts to open a file that has an incorrect filename extension. People on this list have suggested that this is a user problem not a software problem (i.e. that the user was stupid and beyond help), but I can assure you that however obvious the connection between the hidden Windows filename extension and the error message that our program gave is to me and you, it was not obvious to a large number of otherwise very intelligent people who just weren't as knowledgeable about computers. People always think that the icon for a file is somehow part of the file (it makes sense if you don't think about it too hard), and so if a file has, say, a jpeg icon it doesn't occur to them that it is not a jpeg. -Jay From dionney@hotmail.com Fri Jan 2 19:58:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from dionney.dyndns.org (modemcable253.38-203-24.mc.videotron.ca [24.203.38.253]) by mail.gnome.org (Postfix) with ESMTP id B0854182E2; Fri, 2 Jan 2004 19:58:08 -0500 (EST) Received: from [127.0.0.1] (dionney.dyndns.org [127.0.0.1]) by dionney.dyndns.org (Postfix) with ESMTP id F2F9CFD65; Fri, 2 Jan 2004 19:57:59 -0500 (EST) Subject: Re: Suggestion for file type detection approach From: Yves Dionne To: gnome-vfs-list@gnome.org Cc: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1072403221.945.61.camel@hermes.intra.gs2.com.br> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> Content-Type: multipart/mixed; boundary="=-uazmxkOo5iyZC9kUE0ez" Message-Id: <1073091476.23189.12.camel@dionney.dyndns.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 19:57:58 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-uazmxkOo5iyZC9kUE0ez Content-Type: text/plain; charset= Content-Transfer-Encoding: 8bit On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > Why not support recording the mime-type of a file as meta-data (EA) on > > filesystems that support it (every one of them at this point?). It > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > to clearly be the right way to do it. If GNOME VFS supported it then > > it seems it would be easy to implement for alot of applications. > > > > I agree with you, but while we must provide a quick solution, EA (and > the attributes themselves) must be standardized cross-unix and > cross-desktop. This will take some time to mature, since the mechanisms > for sending files through the Internet (between computers, in general) > must mature to support EA. I never used Apple operating systems, but it > looks like they have such a mechanism. Nothing that a tar with EA > support could not do. > > GNOME must provide room today to support state-of-the-art technologies > in the future, but must at the same time provide solutions to today's > users using today's technologies. > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. I thought this could be fun, so hacked gnome-vfs to save the mime type on a EA named "mime_type". When trying to find the mime type for the file, gnome-vfs will first check if this EA exists. If so, use that for the mime type. If not, determine the mime type as usual and save it. It works only for local files. If you don't have permission to change the file, the EA will not be saved. And you need a file system which support EA, of course. I tested it with ext3. Might work with others too. This is a hack, just an exercise to see if it could be beneficial. I did this just for fun. I did not try to follow coding standards, I have no intention of maintaining this patch. Although I might try to hack nautilus to allow changing the mime type (as recorded in the EA). The following patch is against gnome-vfs-2.4.1 as found in Fedora. I attach also a modified SPEC file, just in case someone wants to build it. --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs-2.4.1-attr.patch Content-Type: text/x-patch; name=gnome-vfs-2.4.1-attr.patch; charset= Content-Transfer-Encoding: 7bit diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h gnome-vfs-2.4.1/acconfig.h --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h 2003-09-27 11:42:49.000000000 -0400 +++ gnome-vfs-2.4.1/acconfig.h 2004-01-02 17:11:36.665008680 -0500 @@ -15,6 +15,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in gnome-vfs-2.4.1/config.h.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in 2003-09-01 14:32:48.000000000 -0400 +++ gnome-vfs-2.4.1/config.h.in 2004-01-02 17:11:36.667008376 -0500 @@ -16,6 +16,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in gnome-vfs-2.4.1/configure.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in 2003-10-12 06:51:55.000000000 -0400 +++ gnome-vfs-2.4.1/configure.in 2004-01-02 17:11:36.671007768 -0500 @@ -482,6 +482,22 @@ +dnl *********************** +dnl *** Checks for ATTR *** +dnl *********************** + +ATTR_MISSING_WARNING="Gnome-vfs depends on ATTR" +ATTR_LIBS= +AC_CHECK_LIB(attr, attr_getf, + [AC_CHECK_HEADERS(attr/attributes.h, + [AC_DEFINE(HAVE_ATTR) + ATTR_LIBS="-lattr"], + AC_MSG_WARN(*** ATTR support will not be built (header files not found) $ATTR_MISSING_WARNING ***))], + AC_MSG_WARN(*** ATTR support will not be built (ATTR library not found) $ATTR_MISSING_WARNING ***)) +AC_SUBST(ATTR_LIBS) + + + dnl ************************** dnl *** Checks for gtk-doc *** dnl ************************** diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2003-09-27 11:42:51.000000000 -0400 +++ gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2004-01-02 17:15:50.041489600 -0500 @@ -39,6 +39,9 @@ #include #include #include +#ifdef HAVE_ATTR +#include +#endif static gboolean module_inited = FALSE; @@ -80,6 +83,40 @@ #endif /* G_LOCK_DEFINE_STATIC */ +#ifdef HAVE_ATTR +static GList *mime_attr = NULL; + +static const char * +get_mime_from_ea (FILE *file) +{ + char * mime_type = NULL; + char * buffer = g_alloca (256+1); + GList * p; + int len = 256; + + if (attr_getf (fileno (file), "mime_type", buffer, &len, 0) == 0) { + buffer[len] = 0; + G_LOCK (mime_mutex); + p = g_list_find_custom (mime_attr, buffer, g_ascii_strcasecmp); + if (p != NULL) { + mime_type = p->data; + } else { + mime_type = g_strdup (buffer); + mime_attr = g_list_insert_sorted (mime_attr, mime_type, g_ascii_strcasecmp); + } + G_UNLOCK (mime_mutex); + } + return mime_type; +} + +static void +set_mime_from_ea (FILE *file, const char *mime_type) +{ + int len = strlen (mime_type); + + attr_setf (fileno (file), "mime_type", mime_type, len, 0); +} +#endif static char * get_priority (char *def, int *priority) @@ -337,6 +374,13 @@ g_list_free (mime_regexs [i]); mime_regexs [i] = NULL; } +#ifdef HAVE_ATTR + for (p = mime_attr; p != NULL; p = p->next) { + g_free (p->data); + } + g_list_free (mime_attr); + mime_attr = NULL; +#endif } static void @@ -714,11 +758,22 @@ } if (file != NULL) { +#if HAVE_ATTR + result = get_mime_from_ea (file); + if (result == NULL) + { +#endif buffer = _gnome_vfs_mime_sniff_buffer_new_generic (file_seek_binder, file_read_binder, file); result = _gnome_vfs_get_mime_type_internal (buffer, path); gnome_vfs_mime_sniff_buffer_free (buffer); +#ifdef HAVE_ATTR + if (result != NULL) { + set_mime_from_ea (file, result); + } + } +#endif fclose (file); } else { result = _gnome_vfs_get_mime_type_internal (NULL, path); diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am gnome-vfs-2.4.1/libgnomevfs/Makefile.am --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:10:48.860276104 -0500 +++ gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:11:36.679006552 -0500 @@ -37,6 +37,7 @@ libgnomevfs_2_la_LIBADD = \ $(LIBGNOMEVFS_LIBS) \ + $(ATTR_LIBS) \ $(NULL) libgnomevfs_2_la_LDFLAGS = \ --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs2.spec Content-Type: text/plain; name=gnome-vfs2.spec; charset= Content-Transfer-Encoding: 8bit %define libbonobo_version 2.2.0 %define gconf2_version 1.2.0 %define gtkdoc_version 0.9 %define gnome_mime_data_version 2.0.0-11 %define redhat_menus_version 0.30 %define po_package gnome-vfs-2.0 Summary: The GNOME virtual file-system libraries. Name: gnome-vfs2 Version: 2.4.1 Release: 1 License: LGPL Group: System Environment/Libraries Source: gnome-vfs-%{version}.tar.bz2 Source2: vfolder-desktop-method.c Source3: desktop-method.c URL: http://www.gnome.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-root Requires: gnome-mime-data >= %{gnome_mime_data_version} Requires: redhat-menus >= %{redhat_menus_version} BuildRequires: libbonobo-devel >= %{libbonobo_version} BuildRequires: GConf2-devel >= %{gconf2_version} BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: bonobo-activation-devel, glib2-devel, libxml2-devel, zlib-devel BuildRequires: popt, bzip2-devel, ORBit2-devel, XFree86-devel, openjade BuildRequires: pkgconfig BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: /usr/bin/automake-1.4 BuildRequires: gtk-doc >= %{gtkdoc_version} Prereq: GConf2 >= %{gconf2_version} Patch1: gnome-vfs-1.9.4.91-docdir.patch Patch2: gnome-vfs-2.1.3-moved-menu-files.patch Patch3: gnome-vfs-2.0.4-onlyshowin.patch Patch5: gnome-vfs-1.9.16-moved-menu-files.patch Patch6: gnome-vfs-2.0.1-only-show-in.patch Patch7: gnome-vfs-2.3.7-modules-conf.patch Patch8: gnome-vfs-2.0.2-newstat.patch Patch9: gnome-vfs-2.0.2-read-only.patch ## this is the automake-requiring patch Patch10: gnome-vfs-2.1.6-old-modules.patch Patch11: gnome-vfs-2.1.6-network-uri.patch Patch12: gnome-vfs-2.1.6-never-show-if-empty.patch Patch13: gnome-vfs-2.1.6-hide-with-empty-subfolders.patch Patch14: gnome-vfs-2.1.6-no-private-methods.patch Patch15: gnome-vfs-2.2.0-vfolder-hacks.patch Patch16: gnome-vfs-2.4.1-attr.patch %description GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for file systems, http, ftp, and others. It provides a URI-based API, backend supporting asynchronous file operations, a MIME type manipulation library, and other features. %package devel Summary: Libraries and include files for developing GNOME VFS applications. Group: Development/Libraries Requires: %{name} = %{version} Requires: GConf2-devel >= %{gconf2_version} Requires: libbonobo-devel >= %{libbonobo_version} Conflicts: bonobo-devel < 1.0.8 Conflicts: gnome-vfs-devel < 1.0.2 %description devel This package provides the necessary development libraries for writing GNOME VFS modules and applications that use the GNOME VFS APIs. %prep %setup -q -n gnome-vfs-%{version} cp -f %{SOURCE2} modules cp -f %{SOURCE3} modules # Patch1: gnome-vfs-1.9.4.91-docdir.patch modifies doc/Makefile.am #%patch1 -p1 -b .docdir (cd modules && cp default-modules.conf default-modules.conf.with-menu-editing) ## clean out the methods that don't work with our setup DMC=modules/default-modules.conf.with-menu-editing perl -pi -e 's/all-applications:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/all-preferences:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/favorites:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/network:\s+libvfolder-desktop.so//g' $DMC ## these two should actually work ## perl -pi -e 's/applications-all-users:\s+libvfolder-desktop.so//g' $DMC ## perl -pi -e 's/preferences-all-users:\s+libvfolder-desktop.so//g' $DMC ## these are now in the vfolder-hacks patch #%patch2 -p1 -b .moved-menu-files #%patch3 -p0 -b .onlyshowin %patch5 -p1 -b .moved-menu-files %patch6 -p1 -b .only-show-in %patch7 -p1 -b .modules-conf %patch8 -p1 -b .newstat %patch9 -p1 -b .read-only %patch10 -p1 -b .old-modules %patch11 -p1 -b .network-uri %patch12 -p1 -b .never-show-if-empty %patch13 -p1 -b .hide-with-empty-subfolders %patch14 -p1 -b .no-private-methods %patch15 -p0 -b .vfolder-hacks %patch16 -p1 -b .attr %build # needed for patch10 (changing makefile to old vfolder backend) automake-1.4 # needed for patch16 (changing configure.in for EA) autoconf if pkg-config openssl ; then CPPFLAGS=`pkg-config --cflags openssl`; export CPPFLAGS LDFLAGS=`pkg-config --libs-only-L openssl`; export LDFLAGS fi %configure export tagname=CC make LIBTOOL=/usr/bin/libtool %install rm -fr %{buildroot} export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 export tagname=CC %makeinstall LIBTOOL=/usr/bin/libtool unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL rm -f $RPM_BUILD_ROOT%{_libdir}/gnome-vfs-2.0/modules/lib*.a rm -f $RPM_BUILD_ROOT%{_libdir}/*.la rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default ## why, dear god, why? rm -f $RPM_BUILD_ROOT%{_datadir}/aclocal/gob2.m4 install -m 644 modules/default-modules.conf.with-menu-editing $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/ ## Remove this line and update file list to revert to ## no-menu-editing-by-default # (cd $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/; mv default-modules.conf default-modules.conf.without-menu-editing; mv default-modules.conf.with-menu-editing default-modules.conf) rm -f $RPM_BUILD_ROOT%{_libdir}/bonobo/monikers/*.{a,la} %find_lang %{po_package} %clean rm -fr %{buildroot} %post export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` SCHEMAS="system_http_proxy.schemas" for S in $SCHEMAS; do gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/$S > /dev/null done /sbin/ldconfig %postun -p /sbin/ldconfig %files -f %{po_package}.lang %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README %dir %{_sysconfdir}/gnome-vfs-2.0 %dir %{_sysconfdir}/gnome-vfs-2.0/modules #%dir %{_sysconfdir}/gnome-vfs-2.0/vfolders %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf.with-menu-editing ## we aren't really using the .vfolder-info config files, ## so installing them is a little misleading. ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default %{_bindir}/* %{_libdir}/*.so.* %{_libdir}/gnome-vfs-2.0/modules %dir %{_libdir}/gnome-vfs-2.0 %{_libdir}/bonobo %{_libdir}/vfs %{_sysconfdir}/gconf/schemas/* ## conflicts with gnome-vfs 1, ignore for now ## %{_datadir}/man/man5/* %files devel %defattr(-, root, root) %{_libdir}/lib*.a %{_libdir}/lib*.so %{_libdir}/pkgconfig/* %{_libdir}/gnome-vfs-2.0/include/*.h %{_includedir}/* %{_datadir}/gtk-doc %changelog * Wed Oct 15 2003 Alexander Larsson 2.4.1-1 - Update to 2.4.1, fixes bug #107130 * Tue Sep 9 2003 Alexander Larsson 2.4.0-1 - update to 2.4.0 * Tue Sep 2 2003 Alexander Larsson 2.3.90-1 - update to 2.3.90 * Mon Aug 25 2003 Alexander Larsson 2.3.8-1 - update to 2.3.8 * Mon Aug 11 2003 Alexander Larsson 2.3.7-1 - update for gnome 2.3 * Tue Jul 22 2003 Nalin Dahyabhai 2.2.5-3 - rebuild, setting tagname to CC * Tue Jul 8 2003 Alexander Larsson 2.2.5-2.E - Rebuild * Wed Jun 04 2003 Elliot Lee - rebuilt * Tue May 27 2003 Alexander Larsson 2.2.5-1 - Update to 2.2.5 * Mon Mar 31 2003 Alexander Larsson 2.2.4-1 - Update to 2.2.4 * Mon Feb 24 2003 Elliot Lee - debuginfo rebuild * Mon Feb 24 2003 Alexander Larsson 2.2.2-3 - Added patch to fix smb crash (#84982) * Mon Feb 24 2003 Alexander Larsson 2.2.2-2 - Add patch to fix notify race (#84668) * Wed Feb 12 2003 Alexander Larsson 2.2.2-1 - 2.2.2, fixes bad memleak (#83791) * Tue Feb 11 2003 Havoc Pennington 2.2.1-3 - kill menu editing again, it was very very broken * Mon Feb 10 2003 Bill Nottingham 2.2.1-2 - fix file list (#68226) - prereq GConf2 * Mon Feb 10 2003 Alexander Larsson 2.2.1-1 - Update to 2.2.1. fixes gnome-theme-manager hang * Thu Feb 6 2003 Havoc Pennington 2.2.0-7 - move to menu editing modules.conf by default, we'll see if it works * Tue Jan 28 2003 Matt Wilson 2.2.0-6 - use LIBTOOL=/usr/bin/libtool * Mon Jan 27 2003 Havoc Pennington - it would help to *install* the stupid menu edit conf file - update the vfolder-hacks patch with some fixes * Fri Jan 24 2003 Havoc Pennington - hack up editable vfolder backend to maybe work (still not the default config file) * Wed Jan 22 2003 Havoc Pennington - include a non-default config file to use new vfolder method - build the new vfolder method * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 21 2003 Alexander Larsson - Update to 2.2.0 * Mon Jan 13 2003 Havoc Pennington - variation on the subfolders hack to try to fix it * Sat Jan 11 2003 Havoc Pennington - fix bug where empty folders with empty subfolders would still be visible. * Sat Jan 11 2003 Havoc Pennington - finish adapting desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - adapt desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - hardcode , it's stupid to ever override this. * Sat Jan 11 2003 Havoc Pennington - make network:/// use libdesktop.so, and modify libdesktop.so to support it * Sat Jan 11 2003 Havoc Pennington - Revert to George's vfolder backend from gnome-vfs-2.0.2 or so - put back libdesktop.so - don't build the new vfolder backend * Wed Jan 8 2003 Alexander Larsson 2.1.6-2 - Removed __libdir fix that was fixed upstream * Wed Jan 8 2003 Alexander Larsson 2.1.6-1 - Update to 2.1.6 * Tue Jan 7 2003 Nalin Dahyabhai 2.1.5-3 - rebuild * Mon Dec 16 2002 Tim Powers 2.1.5-2 - rebuild * Mon Dec 16 2002 Alexander Larsson 2.1.5-1 - Update to 2.1.5 * Thu Dec 12 2002 Nalin Dahyabhai - use OpenSSL's pkg-config information, if available * Wed Dec 4 2002 Havoc Pennington - 2.1.3.1 * Sun Nov 10 2002 Havoc Pennington - 2.1.3 - update moved-menu-files patch * Wed Oct 23 2002 Havoc Pennington - add patch for OnlyShowIn support - use plain menu files for .vfolder-info-default - don't install unused vfolder-info files * Tue Oct 8 2002 Havoc Pennington - require new gnome-mime-data in proper libdir - 2.0.4 - drop most patches as they are now upstream or don't apply to new vfolder code * Fri Aug 30 2002 Owen Taylor - Backport a gnome-vfs locking fix from CVS (Hopefully fixes #71419) * Fri Aug 23 2002 Havoc Pennington - make vfolder method read-only #72208 * Mon Aug 19 2002 Jonathan Blandford - notice when new files are installed * Tue Aug 13 2002 Havoc Pennington - don't include pointless .a files * Fri Aug 2 2002 Havoc Pennington - 2.0.2 - use vfolders for system-settings and server-settings * Tue Jul 16 2002 Havoc Pennington - fix OnlyShowIn * Tue Jun 25 2002 Owen Taylor - Version 2.0.1, fix missing po files * Sun Jun 16 2002 Havoc Pennington - 2.0.0 - put schema files in file list, and install them - put libdir/vfs in file list * Tue Jun 11 2002 Havoc Pennington - rebuild in different environment * Tue Jun 11 2002 Havoc Pennington - look for menus in redhat-menus * Fri Jun 07 2002 Havoc Pennington - rebuild in different environment * Wed Jun 5 2002 Havoc Pennington - 1.9.16 * Sun May 26 2002 Tim Powers - automated rebuild * Mon May 20 2002 Havoc Pennington - rebuild in different environment * Mon May 20 2002 Havoc Pennington - 1.9.15 - comment out docdir patch for now * Fri May 3 2002 Havoc Pennington - 1.9.14 * Thu Apr 4 2002 Jeremy Katz - 1.9.11 - update file list * Thu Feb 14 2002 Havoc Pennington - 1.9.7 * Thu Jan 31 2002 Owen Taylor - Fix location of installed docs not to conflict with gnome-vfs1 * Wed Jan 30 2002 Owen Taylor - Rebuild with new libs * Wed Jan 09 2002 Tim Powers - automated rebuild * Thu Jan 3 2002 Havoc Pennington - 1.0.4.91 snap * Mon Nov 26 2001 Havoc Pennington - 1.9.4.90 snap - require gnome-mime-data * Sun Oct 28 2001 Havoc Pennington - new snap, rebuild for glib 1.3.10 * Fri Oct 5 2001 Havoc Pennington - cvs snap * Fri Sep 21 2001 Havoc Pennington - rebuild cvs snap with changes merged upstream - fix a requires - fix up requires/buildrequires a bit * Tue Sep 18 2001 Havoc Pennington - initial gnome-vfs2 build, remove all patches - change config files not to be noreplace * Mon Aug 27 2001 Havoc Pennington - Add po files from sources.redhat.com * Mon Aug 20 2001 Havoc Pennington - fix #51864 (Gimp can't handle file: URIs) * Mon Aug 20 2001 Alexander Larsson 1.0.1-15 - Moved gnome-conf and pkgconfig files to the devel package - Fixes SHOULD-FIX bug #49795 * Mon Aug 6 2001 Alexander Larsson 1.0.1-14 - Added a patch that fixed AbiWord mimetype handling. * Fri Jul 27 2001 Jonathan Blandford - Add .desktop file sniffing * Tue Jul 24 2001 Havoc Pennington - don't do the giant trash scan thing; did not play nice with NFS. * Tue Jul 24 2001 Havoc Pennington - fix desktop-file.conf file * Tue Jul 24 2001 Havoc Pennington - change some URI scheme names * Fri Jul 20 2001 Alexander Larsson - Add pkgconfig and gnome-libs-devel build reqs. - Remove dependency on gnome-vfs-devel by doing some - CPPFLAGS and LDFLAGS magic * Wed Jul 11 2001 Havoc Pennington - add missing directories * Tue Jul 10 2001 Havoc Pennington - fix a segv - change which dirs the desktop VFS module points to * Sun Jul 08 2001 Havoc Pennington - add desktop VFS module hack * Fri Jul 6 2001 Trond Eivind Glomsrød - Remove Distribution and Vendor - Make the config files noreplace - Move .so links to devel subpackage - langify - Add BuildRequires - Don't mess with /etc/ld.so.conf - Use %%{_tmppath} - s/Copyright/License/ * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild. * Wed May 9 2001 Jonathan Blandford - New Version. * Tue Apr 17 2001 Jonathan Blandford - New Version. - clean up spec file some. * Mon Feb 19 2001 Gregory Leblanc - fix paths and macros * Tue Feb 22 2000 Ross Golder - Integrate into source tree --=-uazmxkOo5iyZC9kUE0ez-- From awilliam@whitemice.org Sun Jan 4 08:13:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mail.gnome.org (Postfix) with ESMTP id 7965F183D4; Sun, 4 Jan 2004 08:13:09 -0500 (EST) Received: from adsl-68-72-14-103.dsl.klmzmi.ameritech.net ([68.72.14.103] helo=estate1.whitemice.org) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ad840-0004TY-00; Sun, 04 Jan 2004 05:13:04 -0800 Received: from estate2.whitemice.org (estate2.whitemice.org [192.168.3.245]) by estate1.whitemice.org (8.12.5/8.12.5) with ESMTP id i04DGaAC007033; Sun, 4 Jan 2004 08:16:36 -0500 Subject: Re: Suggestion for file type detection approach From: Adam Williams To: Yves Dionne Cc: gnome-vfs-list@gnome.org, nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain Message-Id: <1073221987.5722.64.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 08:13:07 -0500 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. Yes, please! I mentioned EA awhile ago to no response; sniff, look at extensions, whatever - and keep your results. Even better if applications that created files put the EA tags in themselves. This is so obviously the right solution - Mac OS has been doing this forever, and Winblows is starting to make real use of EA as well. EA follow the file when copied, moved, etc... You could even store a thumbnail in EA and not generate one every time or cache it somewhere annoying like ".nautilus". > It works only for local files. Not sure this is true. The EA on NTFS can be accessed by CIFS calls, and NFSv4 at least supports extended attributes. But maybe niether are ture on Linux at this point. > If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. Works with ext3, XFS, and JFS (at least). > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. Excellent. From dobey@free.fr Sun Jan 4 12:19:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id 1926718685 for ; Sun, 4 Jan 2004 12:19:14 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdBtq-0007Aa-0W; Sun, 04 Jan 2004 12:18:50 -0500 Subject: Re: FUD about security and file extensions (was Re: Why file content sniffing sucks) From: Rodney Dawes To: "Jason A. Pfeil" Cc: Charles Goodwin , Fabio Gomes , Colin Walters , gnome-vfs-list@gnome.org In-Reply-To: References: <1072278440.1486.125.camel@hermes.intra.gs2.com.br> <20031224154241.GK1205@lazarus> <1072281561.4971.11.camel@firebrand> <1072283138.1087.26.camel@discomachinegun.prettypeople.org> <1072291008.15811.3.camel@nexus.verbum.private> <1072401563.945.33.camel@hermes.intra.gs2.com.br> <1072403078.27575.20.camel@mightymax.charlietech.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1073236729.26544.144.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:18:49 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On H=C3=ABn , 2003-12-29 at 10:21, Jason A. Pfeil wrote: > On Fri, 26 Dec 2003, Charles Goodwin wrote: > [...snip...] > > Yes, file sniffing is slow. So implement it in a way that does not > > affect the user. Last time I used Nautilus, I could scroll up and down > > and jump between folders without extra pause, whilst Nautilus updates > > itself in the background. So what is the issue? It only updates what > > is in immediate view (as I recall) so you just scroll to your desired > > file and, if necessary, wait the 2s for it to be detected. >=20 > I think that this is how it was supposed to be implemented, but I don't > believe that this implementation has actually been done. As a quick test= , > open /usr/bin in nautilus. On the box I am using to write this, /usr/bin > has 2,124 files in it. Nautilus took about 10 seconds to load the > contents of that directory. In comparison, use a shell and cd to /usr/bi= n. > Then, type the command: >=20 > echo * >=20 > and see how much faster that returns. echo * returned instantly on my bo= x. > If you want, you can do the echo * method first just so you can convince > yourself that nautilus is not caching things for the shell. And how do I convince myself that echo is doing all of the same activities that nautilus is? Doing a simple "echo *" has substantially less traffic to the X server. It doesn't tell you mime types, modification times, number of files in the child directories, or anything extra about the files. Hell, it doesn't even put the filenames on new lines. If you want to make a comparison like this for mime types, then either compare file and test-mime from the gnome-vfs tests/ directory, on a terminal, while redirecting STDIN and STDOUT to /dev/null, so that terminal X traffic and rendering speed doesn't come in to play. Then you should see that it is not the mime type detection that is slow. The gnome-vfs mime test and file take about the same time to complete. It took less than half a second for gnome-vfs to get the mime types of over 619 files on my system. > Also, when nautilus is opening the directory, take note of the extreme di= sk > churning you hear and note its absence when using the echo * command. FY= I, > the hardware I ran this on is a 1.8GHz P4 with 1GB RAM and U160 SCSI disk > on an Adaptec 7892A controller. Hardly pokey by any standards. Yes. The "echo *" command doesn't open any files at all. It's all done in the command line shell. It simply expands * to all filenames in the current directory, and spits them out on STDOUT. It is not doing anything complex at all. Maybe you should fix The GIMP to use "echo *" when it starts up. It takes a long time to load all those plug-ins. > If we want the average user to use Linux over Windows, we have to have a > system that is competitive not only in security, but also in speed. Whil= e > nautilus has improved greatly over the years, it is still *far* behind > explorer in speed and this file-type identification issue is a prime reas= on. s/Linux/GNOME/ Linux in general is as fast as, if not faster than, Windows. Nautilus is also just as fast as Explorer. Saying X is faster than Y because Y is doing more is ignorant. If Nautilus is slower than Explorer for you, it is a configuration issue, not an issue of how it detects the mime types. You really should spend your time profiling the GNOME libraries and Nautilus if you think your statement is true. Stating your opinion of what is wrong with it won't get it fixed. Proving where the speed bottlenecks are with profiling data and real comparisons with more constants than the hardware it was run on, will be much more useful. > > If Nautilus is wrongly detecting a file type it is a _bug_ and should b= e > > dealt with as such. It is nothing to do with the system used by > > Nautilus. Detection of type by file extension is far more error prone > > and relies much more on correctness of user input which is an > > unreasonable expection on lay users. >=20 > I dispute this notion. Proper training of users (not unreasonable) with = the > help of applications automatically setting file-types will go a long way > towards having good input from users. You can't claim a dispute and then agree. Reasonable training and application assistance will go a long way, yes. However, we shouldn't be relying on user-training. We should be writing applications that help the user to learn on their own. Psychology is a very important aspect to usability. Having a user do something on their own instills pride. Don't you feel like doing more when you do something yourself, as opposed to having to spend $1200 to learn to write a basic web page? Our applications should be smart enough to let the users know what they are doing, and if what they are doing is correct. Also, people migrating from Windows or Mac OS have a bit of training. They generally know enough about icon/label->action associations and similar, that they can figure out things fairly quickly. > [...snip...] > > > The bugs present in Micros~1 Windows are not due to file type detecti= on > > > by suffix.=20 > >=20 > > Wrong, they are. By due nature of the ridiculous method, people > > associate .jpg files or .gif files as images. This introduces a proble= m > > with visual association. > > Somebody gets an email with an attachment such as 'pretty.jpg.exe' or > > 'sexy.gif.pl' and they open it up. Yes, this is due to file type > > detection by suffix because you are subconciously causing people to > > recognise file types by file suffix and hence they can be easily > > mislead. > However, in this type of example, the extensions for both of these files > are .exe and .pl, respectively. Therefore there is no ambiguity since a > file ending in .exe is not a file ending in .jpg and a file ending in .pl > is not a file ending in .gif. The only time that this can cause a proble= m > is when the system *hides* the extension like Windows does. This is a > badly contrived example. No. It goes beyond hiding the extension. Many versions of the file system also only support a maximum of one period in the filename. This really causes problems. The suffix detection also plays a major role, but it is not the only contributing factor. > [...snip...] > >=20 > > One goal of Gnome is to make Free Software desktops a global reality (a= s > > if it already isn't). Introducing notions that add to the confusion > > just to save a few cpu cycles and/or to make things look snappier > > on-the-surface is no way to achieve that goal; unless you want a buggy, > > insecure system but that niche is already well filled. >=20 > Or unless you want to have widespread use. Unfortunately, the average us= er > expects a computer to be fast. By coupling the file extension method wit= h > a type-match check method when the file is opened using nautilus, you get > the best of both worlds. I fail to see the objection. It's just as fast > as the way Windows does it, and it's just as secure as the current way > that nautilus does it. Contriving a conflict is counter-productive. We do have widespread use. Not as widespread as, say, Windows, but still, we have many a user. That user-base is only increasing, as well. The average user does not expect their computer to be as fast as you claim. The average user, uses Windows. Windows is by no means fast. Using both methods of file type detection will gain us nothing. In fact, we already do use both methods. The suffix checking is generally a fall-back method, though. Read the code. It's right there in plain sight. Contriving conflicts is indeed counter-productive. Please stop. :) > > I wish this pointless discussion would go away. It's clogging up my > > inbox. Really, there's some damn clever guys hacking Gnome and this >=20 > You can always unsubscribe to the list or request to get messages in a > digest. However, terminating a discussion because it bores you or is a > minor inconvenience to you is not the right approach. > [...snip...] It's not only an annoyance to him. These mails have been going to far more lists than they should have, if any at all. Continuing a thread simply so that it does go on, is also not the right approach. -- dobey From dobey@free.fr Sun Jan 4 12:47:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id AFA641853E for ; Sun, 4 Jan 2004 12:47:52 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdCLf-0007BI-Ij; Sun, 04 Jan 2004 12:47:35 -0500 Subject: Re: Suggestion for file type detection approach From: Rodney Dawes To: ejk@ucsc.edu Cc: gnome-vfs-list@gnome.org In-Reply-To: <1073083582.3530.77.camel@whipple> References: <1073083582.3530.77.camel@whipple> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1073238454.26541.173.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:47:35 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > >Given the performance bottleneck imposed by sniffing, I suggest that it > >is not used anymore in directory listing routines. It should be used > >when the user tries to open an unknown file. Let's imagine this case: > > I don't think this is a good way of thinking about things. The questions are: > 1. Is sniffing a good idea? > 2. If so does it work correctly? > 3. If (1) and (2), is it performing fast enough? > > I think others have argued persuasively that sniffing is a good idea > since unix doesn't generally give file name suffixes to files (even > though gnome does), and often files have incorrect suffixes. > > A number of people have said that there are instances where sniffing is > not correctly determining the file type. If true, this is an excellent > argument for fixing those cases, but not at all an argument for throwing > away sniffing altogether. I've only seen one person say that. And as I understand, no real information was provided. Only a comment of "it broke on this one file." But yes, it is a good argument for improving the system, not removing the core functionality. > >From your benchmarking it is clear that (3) is a problem, and sniffing > is taking too long. This is not an argument for getting rid of it > though, just an argument for speeding it up. Someone suggested running > it through a profiler, but I doubt that will be worthwhile--the problem > is almost certainly the multiple disk accesses (your disk is having to > seek for each file). As others have pointed out, a two pass technique. > based on extension and then sniffing is also a bad idea since icons, etc > would change in the case of a discrepancy. It is not clear that 3 is a problem. It is only probable that 3 may be an issue on a certain machine with a certain configuration. I guarantee that the sniffing is not the bottleneck. Running it through a profiler will be much more worthwhile than sending mail to a list saying "it's slow." And yes, I am the one that suggested profiling. The disk i/o is most certainly not the bottleneck. Given the speed of hard disks today, seek time is not an issue. Even if it took the 12ms maximum seek time on a newer model hard disk, and you were loading a directory with 1000 files in it, that is only 12 seconds. Given the size of cache on newer hard disks, and the fact that people generally open up the same few folders, rather than opening / and traversing the tree looking for things, or opening odd folders randomly, I would guess that the maximum seek time would be around 3-4 milliseconds. It is much more likely some other problem that is specific to something Nautilus is doing to display the list of files. I also suggested other things than profiling, such as writing specific benchmarks to compare test-mime from gnome-vfs and file, which would be much more useful than saying "Nautilus must be slow because echo * is instantaneous" or other such nonsense. Real benchmarks are much more reliable than "it seemed slow" or "I used a stopwatch", as human error and perception can misinterpret how long it actually took to do something. > Sniffing is slow because it opens every file and reads some of it every > time you open a given directory. If you want to make this fast, cache > filetypes; now opening the huge mp3 folder is just a matter of reading a > single cache file and sniffing those files with a modification time > later than that of the cache file. Naturally this would only need to be > done for those really huge directories, it would probably be a waste for > directories with only a hundred files or fewer. Sniffing is not slow because it opens every file and reads some of it. Though, it may be if you end up opening network mounts, since all of the stat()s are network-bound, which is much slower than local hard disk access. There can surely be improvements in speed for network-bound i/o in gnome-vfs, and improvements in file type detection as well, since most all web server installations on the Internet, are broken. They also generally use filename extensions to determine what to send for the Content-Type: header. This is what gnome-vfs uses currently. > I don't think we need to worry about which approach is ultimately going > to perform faster. For a program like Nautilus either there is or is not > a human-noticeable lag time; improving performance when there is no lag > time is totally pointless. Aye. In general, the speed issues have nothing to do with the way the mime type is detected. Any claims that one is substantially faster than the other, is generally due to misperception. The real issues seem to generally be at a lower level, or totally unrelated, such as the issues with some of the thumbnailers. > A number of people have used Windows as an example of why we don't need > to sniff files; though there are a number of features in Windows worth > copying this is definitely not one of them. I have worked on some > commercial software and the number one frivolous bug report or unfixable > user issue occurs when the user attempts to open a file that has an > incorrect filename extension. People on this list have suggested that > this is a user problem not a software problem (i.e. that the user was > stupid and beyond help), but I can assure you that however obvious the > connection between the hidden Windows filename extension and the error > message that our program gave is to me and you, it was not obvious to a > large number of otherwise very intelligent people who just weren't as > knowledgeable about computers. People always think that the icon for a > file is somehow part of the file (it makes sense if you don't think > about it too hard), and so if a file has, say, a jpeg icon it doesn't > occur to them that it is not a jpeg. Indeed. -- dobey From david@davemalcolm.demon.co.uk Sun Jan 4 19:21:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by mail.gnome.org (Postfix) with ESMTP id 89DF618497; Sun, 4 Jan 2004 19:21:39 -0500 (EST) Received: from davemalcolm.demon.co.uk ([80.177.172.172] helo=[192.168.0.3]) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1AdIV0-000C9Z-0Y; Mon, 05 Jan 2004 00:21:38 +0000 Subject: Re: Suggestion for file type detection approach From: Dave Malcolm To: Yves Dionne Cc: Gnome VFS List , Nautilus List , gnome-list@gnome.org, "gnome-devel-list@gnome.org" In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1073262381.32307.3969.camel@shirehorse1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Jan 2004 00:26:22 +0000 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sat, 2004-01-03 at 00:57, Yves Dionne wrote: > On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > > > Why not support recording the mime-type of a file as meta-data (EA) on > > > filesystems that support it (every one of them at this point?). It > > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > > to clearly be the right way to do it. If GNOME VFS supported it then > > > it seems it would be easy to implement for alot of applications. > > > > > > > I agree with you, but while we must provide a quick solution, EA (and > > the attributes themselves) must be standardized cross-unix and > > cross-desktop. This will take some time to mature, since the mechanisms > > for sending files through the Internet (between computers, in general) > > must mature to support EA. I never used Apple operating systems, but it > > looks like they have such a mechanism. Nothing that a tar with EA > > support could not do. > > > > GNOME must provide room today to support state-of-the-art technologies > > in the future, but must at the same time provide solutions to today's > > users using today's technologies. > > > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > > > Indeed, but it's all we have for now. Now = 2.6. > > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". I think this is a great idea - in particular it gives users something they can adjust if the sniffing gets it wrong. If EAs aren't available, perhaps such "sniff overrides" could be stored using the Nautilus metadata system? Though that would make things even slower. > > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. > > It works only for local files. If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. > > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. From bugtraq@gs2.com.br Mon Jan 5 07:27:19 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from zeus.intra.gs2.com.br (unknown [200.165.137.90]) by mail.gnome.org (Postfix) with ESMTP id 3759218667 for ; Mon, 5 Jan 2004 07:27:17 -0500 (EST) Received: from hermes.intra.gs2.com.br (hermes.intra.gs2.com.br [192.168.1.1]) by zeus.intra.gs2.com.br (Postfix) with ESMTP id 245F0302D1; Mon, 5 Jan 2004 09:33:37 -0300 (BRT) Subject: Re: Suggestion for file type detection approach From: Fabio Gomes To: Rodney Dawes Cc: ejk@ucsc.edu, gnome-vfs-list@gnome.org In-Reply-To: <1073238454.26541.173.camel@blackbox.boston.ximian.com> References: <1073083582.3530.77.camel@whipple> <1073238454.26541.173.camel@blackbox.boston.ximian.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1073305961.1035.25.camel@hermes.intra.gs2.com.br> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 09:32:42 -0300 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Em Dom, 2004-01-04 às 14:47, Rodney Dawes escreveu: > On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > > >Given the performance bottleneck imposed by sniffing, I suggest that it > > >is not used anymore in directory listing routines. It should be used > > >when the user tries to open an unknown file. Let's imagine this case: > > > > I don't think this is a good way of thinking about things. The questions are: > > 1. Is sniffing a good idea? > > 2. If so does it work correctly? > > 3. If (1) and (2), is it performing fast enough? > > > > I think others have argued persuasively that sniffing is a good idea > > since unix doesn't generally give file name suffixes to files (even > > though gnome does), and often files have incorrect suffixes. > > > > A number of people have said that there are instances where sniffing is > > not correctly determining the file type. If true, this is an excellent > > argument for fixing those cases, but not at all an argument for throwing > > away sniffing altogether. > > I've only seen one person say that. And as I understand, no real > information was provided. Only a comment of "it broke on this one file." > But yes, it is a good argument for improving the system, not removing > the core functionality. > > > >From your benchmarking it is clear that (3) is a problem, and sniffing > > is taking too long. This is not an argument for getting rid of it > > though, just an argument for speeding it up. Someone suggested running > > it through a profiler, but I doubt that will be worthwhile--the problem > > is almost certainly the multiple disk accesses (your disk is having to > > seek for each file). As others have pointed out, a two pass technique. > > based on extension and then sniffing is also a bad idea since icons, etc > > would change in the case of a discrepancy. > > It is not clear that 3 is a problem. It is only probable that 3 may be > an issue on a certain machine with a certain configuration. I guarantee > that the sniffing is not the bottleneck. Running it through a profiler > will be much more worthwhile than sending mail to a list saying "it's > slow." And yes, I am the one that suggested profiling. The disk i/o is > most certainly not the bottleneck. Given the speed of hard disks today, > seek time is not an issue. Even if it took the 12ms maximum seek time on > a newer model hard disk, and you were loading a directory with 1000 > files in it, that is only 12 seconds. Given the size of cache on newer > hard disks, and the fact that people generally open up the same few > folders, rather than opening / and traversing the tree looking for > things, or opening odd folders randomly, I would guess that the maximum > seek time would be around 3-4 milliseconds. It is much more likely some > other problem that is specific to something Nautilus is doing to display > the list of files. I also suggested other things than profiling, such > as writing specific benchmarks to compare test-mime from gnome-vfs and > file, which would be much more useful than saying "Nautilus must be slow > because echo * is instantaneous" or other such nonsense. Real benchmarks > are much more reliable than "it seemed slow" or "I used a stopwatch", as > human error and perception can misinterpret how long it actually took to > do something. "ONLY" 12 seconds? Is that acceptable for a directory with 1000 files? Can a human error of perception misinterpret the distance between <1s and 20s multiple times with the help of a stopwatch? You must be kidding. :-P > Aye. In general, the speed issues have nothing to do with the way the > mime type is detected. Any claims that one is substantially faster than > the other, is generally due to misperception. The real issues seem to > generally be at a lower level, or totally unrelated, such as the issues > with some of the thumbnailers. Test it by yourself: http://mail.gnome.org/archives/gnome-devel-list/2004-January/msg00010.html If your results confirm my "misperception", I'll blindly agree with everything that you say. :-) I'm not advocating the removal of functionality. People have already pointed how to fix the performance and misidentification issues in efficient manners. What I am trying to do is show the non-believers where the performance problem actually is. Best regards, -- Fabio Gomes de Souza (+55 81 9127-0597) .- GS2 TECNOLOGIA DA INFORMACAO LTDA :: www.gs2.com.br |- IT Infrastructure :: Security :: Embedded systems :: Linux `- Olinda, Brazil - +55 81 3492-7777 - negocios@gs2.com.br From gkarabin@pobox.com Sat Jan 17 20:36:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id B3AD81820C; Sat, 17 Jan 2004 20:36:20 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0I1aHqG013829; Sat, 17 Jan 2004 17:36:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: federico@gnu.org From: George Karabin Subject: tiff multi-document files Date: Sat, 17 Jan 2004 17:36:16 -0800 To: eog-list@gnome.org, gnome-vfs-list@gnome.org X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Scanning and fax applications sometimes store multiple images in a single image/tiff file. I'd like to modify eog to display multi-image tiff files as a flat collection of files, as if it were a directory. Right now it's ignoring the other images in the file. I want to add a gnome-vfs module to map libtiff's directory feature to a gnome-vfs URI with archive-file-format-like methods. For each image file it opens, eog would test to see if it's image/tiff, and then try to open the directory. If the module's installed, then it'll get a directory handle and create the collection. Does the idea sound OK in principle for eog? I'm not sure how much eog wants to know about file-format-specific stuff like this, so I'm asking up-front. I don't think it makes sense to handle these sorts of files in gdk - this doesn't really map well to the animation interface, and there wouldn't be enough developers using it to justify changing APIs. So if this is done, eog has to learn about this tiff idiosyncrasy. Likewise, does this sound OK for gnome-vfs? I think there's less controversy here, but this is a fairly obscure use case. I can't imagine too many apps actually caring to use this, so I hope it's not considered bloat and a bad dependency. - George From jens@triq.net Sun Jan 18 05:19:55 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail4.ewetel.de (mail4-141.ewetel.de [212.6.122.141]) by mail.gnome.org (Postfix) with ESMTP id 4208118212; Sun, 18 Jan 2004 05:19:55 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-74-180.ewetel.net [80.228.74.180]) by mail4.ewetel.de (8.12.1/8.12.9) with ESMTP id i0IAJqHB026433; Sun, 18 Jan 2004 11:19:53 +0100 (MET) Date: Sun, 18 Jan 2004 11:34:27 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org Subject: Re: tiff multi-document files In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi George, On Sat, 17 Jan 2004, George Karabin wrote: > I want to add a gnome-vfs module to map libtiff's directory feature to > a gnome-vfs URI with archive-file-format-like methods. For each image > file it opens, eog would test to see if it's image/tiff, and then try > to open the directory. If the module's installed, then it'll get a > directory handle and create the collection. Nice. > Does the idea sound OK in principle for eog? I'm not sure how much eog > wants to know about file-format-specific stuff like this, so I'm asking > up-front. I don't think it makes sense to handle these sorts of files > in gdk - this doesn't really map well to the animation interface, and > there wouldn't be enough developers using it to justify changing APIs. > So if this is done, eog has to learn about this tiff idiosyncrasy. > > Likewise, does this sound OK for gnome-vfs? I think there's less > controversy here, but this is a fairly obscure use case. I can't > imagine too many apps actually caring to use this, so I hope it's not > considered bloat and a bad dependency. Actually, I think it should be possible to write a gnome-vfs module, which adds a new URI scheme and handles such tiff files properly. If it behaves like a directory from the gnome-vfs client point of view, eog will automatically use the collection view for this then. I am not very familar with 3rd party gnome-vfs modules, but AFAICS you neither need to touch gnome-vfs nor eog to get this working. Regards, Jens From alexl@redhat.com Mon Jan 19 04:39:29 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 2721E180EB; Mon, 19 Jan 2004 04:39:29 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNl31117; Mon, 19 Jan 2004 04:39:23 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNa09346; Mon, 19 Jan 2004 04:39:23 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0J9d1cG019229; Mon, 19 Jan 2004 04:39:02 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: Jens Finke Cc: George Karabin , eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 19 Jan 2004 10:39:21 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > > Does the idea sound OK in principle for eog? I'm not sure how much eog > > wants to know about file-format-specific stuff like this, so I'm asking > > up-front. I don't think it makes sense to handle these sorts of files > > in gdk - this doesn't really map well to the animation interface, and > > there wouldn't be enough developers using it to justify changing APIs. > > So if this is done, eog has to learn about this tiff idiosyncrasy. > > > > Likewise, does this sound OK for gnome-vfs? I think there's less > > controversy here, but this is a fairly obscure use case. I can't > > imagine too many apps actually caring to use this, so I hope it's not > > considered bloat and a bad dependency. > > Actually, I think it should be possible to write a gnome-vfs module, which > adds a new URI scheme and handles such tiff files properly. If it behaves > like a directory from the gnome-vfs client point of view, eog will > automatically use the collection view for this then. This is called "chained uris", and gnome-vfs has some code for it. However, at the moment it just doesn't work. My hope is that eventually we'll get it fixed though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded vegetarian card sharp with a robot buddy named Sparky. She's a mistrustful paranoid cab driver with her own daytime radio talk show. They fight crime! From gkarabin@pobox.com Mon Jan 19 16:49:06 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from util.ext.ti.com (util.ext.ti.com [192.91.75.135]) by mail.gnome.org (Postfix) with ESMTP id 15A5D180FE for ; Mon, 19 Jan 2004 16:49:06 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by util.ext.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn55O004430 for ; Mon, 19 Jan 2004 15:49:05 -0600 (CST) Received: from sdca.asp.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn4rj024363 for ; Mon, 19 Jan 2004 15:49:04 -0600 (CST) Received: from [146.252.133.9] (HELO pobox.com) by sdca.asp.ti.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 3657067 for gnome-vfs-list@gnome.org; Mon, 19 Jan 2004 13:59:43 -0800 Message-ID: <400C50D0.3090701@pobox.com> Date: Mon, 19 Jan 2004 13:49:04 -0800 From: George J Karabin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gnome-vfs-list@gnome.org Subject: [patch] tar method won't open root directory of archive Content-Type: multipart/mixed; boundary="------------060702050303070000000102" Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------060702050303070000000102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I haven't seen any documentation in gnome-vfs to indicate how one should encode the root directory of an archive into a URI, but empirically, it looks like something like either "foo.tar#tar:" or "foo.tar#tar:/" should work (gnome-vfs expands the former to the latter before giving the uri to the module's method). The tar method doesn't handle either of these cases. The attached patch fixes this. Try out something like "gnomevfs-ls /path-to-file/foo.tar#:" before and after the patch as a test case. No CVS access for me - can someone apply it if it passes review? The problem's filed in bugzilla as well: http://bugzilla.gnome.org/show_bug.cgi?id=131959 - George --------------060702050303070000000102 Content-Type: text/plain; name="gnome-vfs-2.4.1-handle-root.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gnome-vfs-2.4.1-handle-root.patch" --- gnome-vfs-2.4.1/modules/tar-method.c.handle-root 2002-05-12 20:38:29.000000000 -0700 +++ gnome-vfs-2.4.1/modules/tar-method.c 2004-01-19 12:43:14.000000000 -0800 @@ -51,6 +51,7 @@ int current_index; gchar *filename; gboolean is_directory; + gboolean is_root; } FileHandle; #define TARPET_BLOCKSIZE (sizeof (union TARPET_block)) @@ -154,35 +155,42 @@ return ret; } -static GNode* -tree_lookup_entry (const GNode *tree, const gchar *name) +static gboolean +tree_lookup_entry (const GNode *tree, const gchar *name, GNode **node) { - GNode *ret; char *root = g_strdup (name); char *txt = root; - - if (txt[0] == '/') - txt++; - ret = real_lookup_entry (tree, txt, 1); - if (!ret && txt[strlen (txt) - 1] != '/') + if (txt[0] == '/') + { + if (txt[1] == '\0') + { + g_free (root); + return TRUE; + } + else + txt++; + } + + *node = real_lookup_entry (tree, txt, 1); + if (!*node && txt[strlen (txt) - 1] != '/') { txt = g_strconcat (txt, "/", NULL); g_free (root); root = txt; - ret = real_lookup_entry (tree, txt, 1); + *node = real_lookup_entry (tree, txt, 1); } g_free (root); - if (ret && ret != tree->children) + if (*node && *node != tree->children) { - union TARPET_block *b = ret->data; + union TARPET_block *b = (*node)->data; b--; if (b->p.typeflag == TARPET_TYPE_LONGFILEN) - ret = ret->next; + *node = (*node)->next; } - return ret; + return FALSE; } static TarFile* read_tar_file (GnomeVFSHandle *handle) @@ -228,7 +236,7 @@ } split_name (ret->blocks[i].p.name, &dir, &rest); - node = tree_lookup_entry (ret->info_tree, dir); + tree_lookup_entry (ret->info_tree, dir, &node); if (!node) { @@ -322,7 +330,7 @@ tar = ensure_tarfile (uri); if (!tar) return GNOME_VFS_ERROR_BAD_FILE; - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); if (!node) { tar_file_unref (tar); @@ -468,13 +476,17 @@ union TARPET_block *start, *current; GNode *node; int i; + gboolean is_root; if (!uri->parent) return GNOME_VFS_ERROR_INVALID_URI; tar = ensure_tarfile (uri); if (uri->text) { - node = tree_lookup_entry (tar->info_tree, uri->text); + is_root = tree_lookup_entry (tar->info_tree, uri->text, &node); + } + if (!is_root) + { if (!node) { tar_file_unref (tar); @@ -490,8 +502,11 @@ else current = NULL; } - else + if (is_root || !uri->text) { + /* FIXME: gnome-vfs never seems to generate !uri->text + condition. Is it permissible by contract? */ + node = tar->info_tree; if (!node) { @@ -516,6 +531,7 @@ break; new_handle->current_index = i; new_handle->is_directory = TRUE; + new_handle->is_root = is_root; *method_handle = (GnomeVFSMethodHandle*) new_handle; @@ -550,7 +566,7 @@ int i; if (uri->text) - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); else node = tar->info_tree->children; @@ -635,15 +651,16 @@ GnomeVFSURI *uri; gchar *str; GNode *node; - + gboolean is_root; + if (!handle->current) return GNOME_VFS_ERROR_EOF; str = g_strconcat (handle->filename, "#tar:", handle->current->p.name, NULL); uri = gnome_vfs_uri_new (str); do_get_file_info (method, uri, file_info, 0, context); - node = tree_lookup_entry (handle->tar->info_tree, uri->text); - if (!node) + is_root = tree_lookup_entry (handle->tar->info_tree, uri->text, &node); + if (!node && !is_root) { gnome_vfs_uri_unref (uri); return GNOME_VFS_ERROR_NOT_FOUND; --------------060702050303070000000102-- From cbhoh@yahoo.com Tue Jan 20 01:36:27 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60307.mail.yahoo.com (web60307.mail.yahoo.com [216.109.118.118]) by mail.gnome.org (Postfix) with SMTP id 58F7518675 for ; Tue, 20 Jan 2004 01:36:27 -0500 (EST) Message-ID: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Received: from [161.142.100.80] by web60307.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 22:36:27 PST Date: Mon, 19 Jan 2004 22:36:27 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: gnome_vfs_get_mime_type does NOT get the mime_type To: gnome-vfs-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi guys, I need some help here, today I just use jhbuild to rebuild the 2.5 gnome. I noticed that the gnome_vfs_get_mime_type or gnome_vfs_get_mime_type_from_uri does not work. since the latest yelp use the gnome-vfs to determine the correct mimetype and then respond to the help file according to mime-type. For whatever file I use gnome_vfs_get_mime_type to retrive, I keep getting application/octect-stream. Is there anything i miss out about ? HOH ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Tue Jan 20 02:17:30 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id 9E92818136; Tue, 20 Jan 2004 02:17:29 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0K7HPqG014225; Mon, 19 Jan 2004 23:17:25 -0800 (PST) In-Reply-To: <1074505161.2413.109.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Mon, 19 Jan 2004 23:17:26 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: >> Actually, I think it should be possible to write a gnome-vfs module, >> which >> adds a new URI scheme and handles such tiff files properly. If it >> behaves >> like a directory from the gnome-vfs client point of view, eog will >> automatically use the collection view for this then. > > This is called "chained uris", and gnome-vfs has some code for it. > However, at the moment it just doesn't work. My hope is that eventually > we'll get it fixed though. I looked at the archives for this list on chaining and the shared vfs ideas on xdg-list. Has anything come of your idea for a common VFS URI spec: https://listman.redhat.com/archives/xdg-list/2003-September/ msg00110.html ? Do you think it makes any sense to attempt to fix chaining before attempting such a spec? Regarding a VFS URI spec, I thought I'd go looking for relevant internet standards and drafts, and note them here. They might make for some good references for requirements gathering for anyone thinking about such a spec. Anyway, RFC 2396 provides a general BNF for URIs that seems workable[1]. RFC 2396bis was in the running to succeed it, but expired in December. It had expanded on encoding and escaping guidelines, which 2396 was really vague on, but basically left the specifics for URI components to TBD docs that describe those URIs. I.e., no conclusive help here anytime soon. I don't know why it lost momentum, and am not sure if there's any sense trying to salvage some of its ideas or not. Maybe it makes sense to get URIs that VFS projects care about into ietf drafts? Looks to be a slow-moving standards body - dunno if it's worth the effort or not - I don't have any experience with standards bodies. RFC 1738 provides rules for some specific URI types. RFC1738bis is an update based on 2396bis, so it's left hanging as well. The ssh URI draft that Jeff Waugh referred to some time back is based on other drafts that are based on the expired 2396bis, so it seems likely that it'll expire as well unless 239bis picks up again. Interesting RFCs: ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt ftp://ftp.rfc-editor.org/in-notes/rfc2079.txt ftp://ftp.rfc-editor.org/in-notes/rfc2483.txt ftp://ftp.rfc-editor.org/in-notes/rfc2168.txt Other relevant/interesting drafts: http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri- rfc2396bis-03.txt (expired) http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-06.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri -01.txt - George [1] It's old enough that for all I know gnome-vfs or kio could be based on it. I have no idea if that's the case or not. From alexl@redhat.com Tue Jan 20 03:00:52 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9DB8618958; Tue, 20 Jan 2004 03:00:52 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80ql14111; Tue, 20 Jan 2004 03:00:52 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80qa30628; Tue, 20 Jan 2004 03:00:52 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0K80UcG000940; Tue, 20 Jan 2004 03:00:31 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040120063627.8391.qmail@web60307.mail.yahoo.com> References: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074585650.2413.185.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 20 Jan 2004 09:00:51 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 07:36, Chee Bin HOH wrote: > Hi guys, > > I need some help here, today I just use jhbuild to > rebuild the 2.5 gnome. I noticed that the > gnome_vfs_get_mime_type or > gnome_vfs_get_mime_type_from_uri does not work. > > since the latest yelp use the gnome-vfs to determine > the correct mimetype and then respond to the help file > according to mime-type. > > For whatever file I use gnome_vfs_get_mime_type to > retrive, I keep getting application/octect-stream. > > Is there anything i miss out about ? Did you install shared-mime-info? Did you set XDG_DATA_DIRS to include $prefix/share? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a globe-trotting skateboarding hairdresser who dotes on his loving old ma. She's a foxy cat-loving barmaid with an incredible destiny. They fight crime! From cbhoh@yahoo.com Wed Jan 21 01:47:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60309.mail.yahoo.com (web60309.mail.yahoo.com [216.109.118.120]) by mail.gnome.org (Postfix) with SMTP id 59D2718254 for ; Wed, 21 Jan 2004 01:47:13 -0500 (EST) Message-ID: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Received: from [161.142.195.153] by web60309.mail.yahoo.com via HTTP; Tue, 20 Jan 2004 21:20:17 PST Date: Tue, 20 Jan 2004 21:20:17 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074585650.2413.185.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --- Alexander Larsson wrote: > Did you install shared-mime-info? Did you set > XDG_DATA_DIRS to include > $prefix/share? I did install share-mime-info from cvs.freedesktop.org (as requested by jhbuild), but I did not set the env XDG_DATA_DIRS. I need to set XDG_DATA_DIRS while I build share-mime-info or others? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a globe-trotting skateboarding hairdresser who > dotes on his loving old > ma. She's a foxy cat-loving barmaid with an > incredible destiny. They fight > crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From alexl@redhat.com Wed Jan 21 05:27:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9AF4B181E9; Wed, 21 Jan 2004 05:27:50 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARol29294; Wed, 21 Jan 2004 05:27:50 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARoa13682; Wed, 21 Jan 2004 05:27:50 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LARScG018691; Wed, 21 Jan 2004 05:27:28 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040121052017.24059.qmail@web60309.mail.yahoo.com> References: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074680868.2413.359.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:49 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > --- Alexander Larsson wrote: > > Did you install shared-mime-info? Did you set > > XDG_DATA_DIRS to include > > $prefix/share? > > I did install share-mime-info from cvs.freedesktop.org > (as requested by jhbuild), but I did not set the env > XDG_DATA_DIRS. > > I need to set XDG_DATA_DIRS while I build > share-mime-info or others? No, not while building. You need to set it when running apps. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a genetically engineered vegetarian inventor with a winning smile and a way with the ladies. She's a beautiful nymphomaniac research scientist on the trail of a serial killer. They fight crime! From alexl@redhat.com Wed Jan 21 05:27:13 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 37B74181E9; Wed, 21 Jan 2004 05:27:13 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBl29170; Wed, 21 Jan 2004 05:27:11 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBa13574; Wed, 21 Jan 2004 05:27:11 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LAQmcG018568; Wed, 21 Jan 2004 05:26:49 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org In-Reply-To: References: <1074505161.2413.109.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:09 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 08:17, George Karabin wrote: > On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > > > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > >> Actually, I think it should be possible to write a gnome-vfs module, > >> which > >> adds a new URI scheme and handles such tiff files properly. If it > >> behaves > >> like a directory from the gnome-vfs client point of view, eog will > >> automatically use the collection view for this then. > > > > This is called "chained uris", and gnome-vfs has some code for it. > > However, at the moment it just doesn't work. My hope is that eventually > > we'll get it fixed though. > > > I looked at the archives for this list on chaining and the shared vfs > ideas on xdg-list. Has anything come of your idea for a common VFS URI > spec: > https://listman.redhat.com/archives/xdg-list/2003-September/ > msg00110.html ? Do you think it makes any sense to attempt to fix > chaining before attempting such a spec? There hasn't been any work on it that I know of. And in such a spec it would be nice if chaining was supported. > Regarding a VFS URI spec, I thought I'd go looking for relevant > internet standards and drafts, and note them here. They might make for > some good references for requirements gathering for anyone thinking > about such a spec. In some sense its sort of unfortunate that gnome-vfs uris are based on normal URIs, because that limits us a bit and in some cases it causes trouble because people expect that gnome-vfs should support all sorts of things you can do with web-uris, such as mailto:, callto:, javascript: etc. In fact, we partially handle these by installing handler app settings for them, but in reality they are not really gnome-vfs uris. The way gnome-vfs currently handles chained uris is described in gnome-vfs/doc/uri.txt. Its working to some extent, but the work has never really been finalized and polished up to work in the desktop. To make it work you'd have to: * Work on the chained methods (zip, tar, gzip etc) to make them work better than they do today. The existance of the gnome-vfs daemon in 2.5 should make this easier * Finish the work with putting chained uri handlers into the mime info, so that the file manager can now what file types are chainable * Make the file handler recognize chainable file types and browse them * Make all users of gnome-vfs correctly handle chained uris (i.e. gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns file:///some/file.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an old-fashioned day-dreaming Green Beret possessed of the uncanny powers of an insect. She's a cold-hearted antique-collecting hooker married to the Mob. They fight crime! From cbhoh@yahoo.com Wed Jan 21 06:22:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60306.mail.yahoo.com (web60306.mail.yahoo.com [216.109.118.117]) by mail.gnome.org (Postfix) with SMTP id 9AC8718422 for ; Wed, 21 Jan 2004 06:22:51 -0500 (EST) Message-ID: <20040121112245.44069.qmail@web60306.mail.yahoo.com> Received: from [161.142.195.41] by web60306.mail.yahoo.com via HTTP; Wed, 21 Jan 2004 03:22:45 PST Date: Wed, 21 Jan 2004 03:22:45 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074680868.2413.359.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hey, it works. ;) Thank! --- Alexander Larsson wrote: > On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > > --- Alexander Larsson wrote: > > > Did you install shared-mime-info? Did you set > > > XDG_DATA_DIRS to include > > > $prefix/share? > > > > I did install share-mime-info from > cvs.freedesktop.org > > (as requested by jhbuild), but I did not set the > env > > XDG_DATA_DIRS. > > > > I need to set XDG_DATA_DIRS while I build > > share-mime-info or others? > > No, not while building. You need to set it when > running apps. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a genetically engineered vegetarian inventor > with a winning smile and a > way with the ladies. She's a beautiful nymphomaniac > research scientist on the > trail of a serial killer. They fight crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Sat Jan 24 00:53:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-03-eri0.socal.rr.com (ms-smtp-03-qfe0.socal.rr.com [66.75.162.135]) by mail.gnome.org (Postfix) with ESMTP id 73D0A182A2; Sat, 24 Jan 2004 00:53:14 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-03-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0O5rAF3022083; Fri, 23 Jan 2004 21:53:11 -0800 (PST) In-Reply-To: <1074680829.2413.357.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9618B740-4E31-11D8-B6FD-000A95A6935E@pobox.com> Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Fri, 23 Jan 2004 21:53:08 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 21, 2004, at 2:27 AM, Alexander Larsson wrote: > In some sense its sort of unfortunate that gnome-vfs uris are based on > normal URIs, because that limits us a bit and in some cases it causes > trouble because people expect that gnome-vfs should support all sorts > of > things you can do with web-uris, such as mailto:, callto:, javascript: > etc. In fact, we partially handle these by installing handler app > settings for them, but in reality they are not really gnome-vfs uris. Regarding the IETF docs, the thing I'm most interested in is to be sure that the grammar that they publish for URIs are the same as what gnome-vfs uses, so that URIs that are appropriate to the VFS can be generated from some external source, and be handled by a gnome-vfs client that doesn't necessarily know it's content. > The way gnome-vfs currently handles chained uris is described in > gnome-vfs/doc/uri.txt. Its working to some extent, but the work has > never really been finalized and polished up to work in the desktop. > Thanks - the text files aren't in the release tarballs. Looking at them in cvs helps out a lot. > To make it work you'd have to: > * Work on the chained methods (zip, tar, gzip etc) to make them work > better than they do today. The existance of the gnome-vfs daemon in 2.5 > should make this easier > * Finish the work with putting chained uri handlers into the mime info, > so that the file manager can now what file types are chainable > * Make the file handler recognize chainable file types and browse them > * Make all users of gnome-vfs correctly handle chained uris (i.e. > gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns > file:///some/file.) Thanks for the laundry list - I can start working toward these. I'll be away from email for a few days, but I'll be working my way through the new code over the course of the week. - George From thomas.cataldo@aliacom.fr Sun Jan 25 09:14:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0902.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 36753187E9 for ; Sun, 25 Jan 2004 09:14:21 -0500 (EST) Received: from localhost (AToulouse-206-1-16-219.w81-50.abo.wanadoo.fr [81.50.219.219]) by mwinf0902.wanadoo.fr (SMTP Server) with ESMTP id 8F0FD18000CC for ; Sun, 25 Jan 2004 15:14:19 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 0A33410712E for ; Sun, 25 Jan 2004 15:09:12 +0100 (CET) Subject: [PATCH] nntp method leak fixes From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-P0V5Zy6gc1b7U4iju1UH" Message-Id: <1075039751.12033.9.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 25 Jan 2004 15:09:12 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-P0V5Zy6gc1b7U4iju1UH Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Here is a patch to fix a few leaks in the nntp method. I tested it using gnomevfs-ls nntp:///alt.binaries.anime regards, Thomas. --=-P0V5Zy6gc1b7U4iju1UH Content-Disposition: attachment; filename=nntp-method-leaks.diff Content-Type: text/x-patch; name=nntp-method-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1715 diff -u -r1.1715 ChangeLog --- ChangeLog 23 Jan 2004 09:59:44 -0000 1.1715 +++ ChangeLog 25 Jan 2004 13:58:56 -0000 @@ -1,3 +1,8 @@ +2004-01-25 Thomas Cataldo + + * modules/nntp-method.c: (parse_date_string), (parse_header): some + memory leak fixes. + 2004-01-23 Alexander Larsson * schemas/Makefile.am: Index: modules/nntp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/nntp-method.c,v retrieving revision 1.5 diff -u -r1.5 nntp-method.c --- modules/nntp-method.c 16 Jun 2002 23:43:35 -0000 1.5 +++ modules/nntp-method.c 25 Jan 2004 13:58:57 -0000 @@ -814,6 +814,12 @@ g_message("error parsing %s, %s", date_string, temp_str); } + if (filename != NULL) { + g_free (filename); + } + if (linkname != NULL) { + g_free (linkname); + } g_free(temp_str); *t = s.st_mtime; @@ -904,6 +910,8 @@ file_start = strrchr (temp_str, '-'); if (file_start == NULL) { + g_free (*message_id); + g_free (temp_str); return FALSE; } --=-P0V5Zy6gc1b7U4iju1UH-- From cbhoh@mimos.my Wed Jan 28 05:45:42 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Jan 2004 18:39:13 +0800 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH From thomas.cataldo@aliacom.fr Thu Jan 29 21:06:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0904.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 32FD318B2C for ; Thu, 29 Jan 2004 21:06:53 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0904.wanadoo.fr (SMTP Server) with ESMTP id 951C0180012A for ; Fri, 30 Jan 2004 03:06:49 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 82288106FD4 for ; Fri, 30 Jan 2004 03:00:53 +0100 (CET) Subject: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-vEputk1gGiSFtfo2JnkO" Message-Id: <1075428053.15247.11.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 03:00:53 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-vEputk1gGiSFtfo2JnkO Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests agains ftp and http urls. By the way, as my previous patch against the nntp method was not reviewed, could you tell me if this list is the right place to send patches, or if a bug report is a better way. cheers, Thomas. --=-vEputk1gGiSFtfo2JnkO Content-Disposition: attachment; filename=vfs-socket-leaks.diff Content-Type: text/x-patch; name=vfs-socket-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1716 diff -u -r1.1716 ChangeLog --- ChangeLog 27 Jan 2004 18:59:08 -0000 1.1716 +++ ChangeLog 30 Jan 2004 01:55:40 -0000 @@ -1,3 +1,12 @@ +2004-01-30 Thomas Cataldo + + plug some gnome_vfs_socket leaks. + + * libgnomevfs/gnome-vfs-socket-buffer.c: + (gnome_vfs_socket_buffer_destroy): + * modules/ftp-method.c: (do_transfer_command), (end_transfer), + (ftp_connection_create), (ftp_connection_destroy): + 2004-01-27 David Hawthorne * daemon/gnome-vfs-daemon.c Index: libgnomevfs/gnome-vfs-socket-buffer.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/libgnomevfs/gnome-vfs-socket-buffer.c,v retrieving revision 1.8 diff -u -r1.8 gnome-vfs-socket-buffer.c --- libgnomevfs/gnome-vfs-socket-buffer.c 15 Jan 2004 09:55:51 -0000 1.8 +++ libgnomevfs/gnome-vfs-socket-buffer.c 30 Jan 2004 01:55:41 -0000 @@ -104,6 +104,7 @@ if (close_socket) { gnome_vfs_socket_close (socket_buffer->socket); + g_free(socket_buffer->socket); } g_free (socket_buffer); return GNOME_VFS_OK; Index: modules/ftp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/ftp-method.c,v retrieving revision 1.96 diff -u -r1.96 ftp-method.c --- modules/ftp-method.c 22 Jan 2004 12:29:10 -0000 1.96 +++ modules/ftp-method.c 30 Jan 2004 01:55:44 -0000 @@ -62,14 +62,12 @@ typedef struct { GnomeVFSMethodHandle method_handle; - GnomeVFSInetConnection *inet_connection; GnomeVFSSocketBuffer *socket_buf; GnomeVFSURI *uri; gchar *cwd; GString *response_buffer; gchar *response_message; gint response_code; - GnomeVFSInetConnection *data_connection; GnomeVFSSocketBuffer *data_socketbuf; GnomeVFSFileOffset offset; enum { @@ -384,6 +382,7 @@ char *host = NULL; gint port; GnomeVFSResult result; + GnomeVFSInetConnection *data_connection; GnomeVFSSocket *socket; /* Image mode (binary to the uninitiated) */ @@ -414,7 +413,7 @@ } /* connect */ - result = gnome_vfs_inet_connection_create (&conn->data_connection, + result = gnome_vfs_inet_connection_create (&data_connection, host, port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -424,16 +423,10 @@ return result; } - socket = gnome_vfs_inet_connection_to_socket (conn->data_connection); + socket = gnome_vfs_inet_connection_to_socket (data_connection); conn->data_socketbuf = gnome_vfs_socket_buffer_new (socket); - if (conn->socket_buf == NULL) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - return GNOME_VFS_ERROR_GENERIC; - } - - if (conn->offset) - { + if (conn->offset) { gchar *tmpstring; tmpstring = g_strdup_printf ("REST %Lu", conn->offset); @@ -441,8 +434,7 @@ g_free (tmpstring); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } } @@ -450,16 +442,14 @@ result = do_control_write (conn, command); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } result = get_response (conn); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } @@ -501,15 +491,10 @@ if(conn->data_socketbuf) { gnome_vfs_socket_buffer_flush (conn->data_socketbuf); - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); conn->data_socketbuf = NULL; } - if (conn->data_connection) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - conn->data_connection = NULL; - } - result = get_response (conn); return result; @@ -545,6 +530,7 @@ gint port = control_port; const gchar *user = anon_user; const gchar *pass = anon_pass; + GnomeVFSInetConnection* inet_connection; conn->uri = gnome_vfs_uri_dup (uri); conn->response_buffer = g_string_new (""); @@ -565,7 +551,7 @@ pass = gnome_vfs_uri_get_password (uri); } - result = gnome_vfs_inet_connection_create (&conn->inet_connection, + result = gnome_vfs_inet_connection_create (&inet_connection, gnome_vfs_uri_get_host_name (uri), port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -581,11 +567,11 @@ return result; } - conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (conn->inet_connection); + conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (inet_connection); if (conn->socket_buf == NULL) { g_warning ("Getting socket buffer failed"); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_inet_connection_destroy (inet_connection, NULL); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -612,8 +598,7 @@ /* login failed */ g_warning ("FTP server said: \"%d %s\"\n", conn->response_code, conn->response_message); - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -645,11 +630,8 @@ ftp_connection_destroy (FtpConnection *conn) { - if (conn->inet_connection) - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); - if (conn->socket_buf) - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_free (conn->cwd); @@ -659,11 +641,8 @@ g_free (conn->response_message); g_free (conn->server_type); - if (conn->data_connection) - gnome_vfs_inet_connection_destroy(conn->data_connection, NULL); - if (conn->data_socketbuf) - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); g_free (conn->dirlist); g_free (conn->dirlistptr); --=-vEputk1gGiSFtfo2JnkO-- From alexl@redhat.com Fri Jan 30 03:05:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 42D57182E3 for ; Fri, 30 Jan 2004 03:05:39 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Vb24660; Fri, 30 Jan 2004 03:05:31 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Ua05769; Fri, 30 Jan 2004 03:05:30 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0U853kC017335; Fri, 30 Jan 2004 03:05:04 -0500 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Alexander Larsson To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Message-Id: <1075449929.8585.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 30 Jan 2004 09:05:29 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > Hi, > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > agains ftp and http urls. > > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. Nah, it works. Christophe or I will get to it eventually. I'm just horribly busy with other stuff at the moment. Your first patch is tagged in my inbox and will get attention when i have time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded coffee-fuelled cop from a doomed world. She's a strong-willed thirtysomething Valkyrie descended from a line of powerful witches. They fight crime! From thomas.cataldo@aliacom.fr Fri Jan 30 03:13:22 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0901.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id C0FDC18FF9 for ; Fri, 30 Jan 2004 03:13:10 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0901.wanadoo.fr (SMTP Server) with ESMTP id 8EA02180021B; Fri, 30 Jan 2004 09:13:02 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id D1619106FD4; Fri, 30 Jan 2004 09:07:03 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Alexander Larsson Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075449929.8585.37.camel@localhost.localdomain> References: <1075428053.15247.11.camel@buffy> <1075449929.8585.37.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1075450023.15247.13.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 09:07:03 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 09:05, Alexander Larsson wrote: > On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > > Hi, > > > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > > agains ftp and http urls. > > > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > Nah, it works. Christophe or I will get to it eventually. I'm just > horribly busy with other stuff at the moment. Your first patch is tagged > in my inbox and will get attention when i have time. Ok, thanks for the quick reply. From root@cavtel.net Thu Jan 29 17:38:23 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from xx.mx.cavtel.net (xx.mx.cavtel.net [64.83.1.45]) by mail.gnome.org (Postfix) with ESMTP id 5A15618E5F; Thu, 29 Jan 2004 17:38:23 -0500 (EST) Received: by xx.mx.cavtel.net (Postfix, from userid 0) id CEE681D42C8; Thu, 29 Jan 2004 17:38:22 -0500 (EST) Received: from msg2.cavtel.net (msg2.mx.cavtel.net [64.83.1.144]) by xx.mx.cavtel.net (Postfix) with ESMTP id 96E8A4382D for ; Wed, 28 Jan 2004 06:17:55 -0500 (EST) Received: by msg2.cavtel.net (Postfix, from userid 1002) id B49283139E; Wed, 28 Jan 2004 06:02:41 -0500 (EST) Received: from mail.gnome.org (moniker.gnome.org [67.72.78.218]) by msg2.cavtel.net (Postfix) with ESMTP id 3E3E431B89 for ; Wed, 28 Jan 2004 05:58:12 -0500 (EST) Received: from moniker.gnome.org (moniker.gnome.org [127.0.0.1]) by mail.gnome.org (Postfix) with ESMTP id A8B08184D1; Wed, 28 Jan 2004 05:59:25 -0500 (EST) Delivered-To: desktop-devel-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Content-Transfer-Encoding: 7bit X-BeenThere: desktop-devel-list@gnome.org X-Loop: desktop-devel-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Date: 28 Jan 2004 18:39:13 +0800 X-Bayesian-Class: No, tests=bogofilter, spamicity=0.188133, version=0.15.8 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list From cfergeau@mipsys.com Fri Jan 30 04:11:12 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from bugsbunny.mipsys.com (griffon.mipsys.com [217.167.51.129]) by mail.gnome.org (Postfix) with ESMTP id 1651918A96 for ; Fri, 30 Jan 2004 04:11:12 -0500 (EST) Received: from teuf by bugsbunny.mipsys.com with local (Exim 3.36 #1 (Debian)) id 1AmUfU-0003Nj-00; Fri, 30 Jan 2004 10:10:28 +0100 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Christophe Fergeau To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1075453828.3843.0.camel@bugsbunny.mipsys.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.3 Date: Fri, 30 Jan 2004 10:10:28 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. I prefer having a bug report in addition to mails since I regularly check the pending bugs in bugzilla, and process them as I find time. Christophe From thomas.cataldo@aliacom.fr Fri Jan 30 04:37:20 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail.aliacom.fr (mail.aliacom.fr [213.41.82.82]) by mail.gnome.org (Postfix) with ESMTP id BCDC318FF1; Fri, 30 Jan 2004 04:37:19 -0500 (EST) Received: from chienne.aliacom-local (chienne.aliacom-local [192.168.1.38]) by mail.aliacom.fr (Postfix) with ESMTP id D2AE7202DC; Fri, 30 Jan 2004 10:37:17 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Christophe Fergeau Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075453828.3843.0.camel@bugsbunny.mipsys.com> References: <1075428053.15247.11.camel@buffy> <1075453828.3843.0.camel@bugsbunny.mipsys.com> Content-Type: text/plain Organization: Aliacom Message-Id: <1075455508.14823.17.camel@chienne.aliacom-local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 10:38:28 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 10:10, Christophe Fergeau wrote: > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > I prefer having a bug report in addition to mails since I regularly > check the pending bugs in bugzilla, and process them as I find time. My two patches (nttp and ftp/http leaks) are filed as bugs #132950 and #132951 regards, Thomas. From jitendra.moon@wipro.com Sun Jan 4 04:11:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by mail.gnome.org (Postfix) with ESMTP id 4E185185D5 for ; Sun, 4 Jan 2004 04:11:51 -0500 (EST) Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i049BnOZ025386 for ; Sun, 4 Jan 2004 14:41:49 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Sun, 04 Jan 2004 14:42:58 +0530 Received: from chn-snr-bh3.wipro.com ([10.145.50.93]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from hyd-mdp-msg.wipro.com ([10.150.50.99]) by chn-snr-bh3.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Received: from mdpnok109242 ([192.168.142.126]) by hyd-mdp-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2004 14:41:48 +0530 Reply-To: From: "Jitendra Moon" To: Date: Sun, 4 Jan 2004 14:46:14 +0530 Message-ID: <000601c3d2a3$67495ff0$b786a8c0@mdpnok109242> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3D2D1.81019BF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 04 Jan 2004 09:11:48.0301 (UTC) FILETIME=[C8450FD0:01C3D2A2] Subject: (no subject) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 I have installed gnome-vfs-2.0 on my debian box. Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs API=92s. Any sample code in this regard will be of great help. =20 Are only gnome vfs libraries sufficient to access above mentioned device file systems on debian Linux? Or do we need to install some thing more on top of gnome VFS? =20 Again any sample code will be of great help. =20 =20 =20 Jitendra Moon =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0007_01C3D2D1.81019BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

I have installed gnome-vfs-2.0 on my debian = box.

Does some one has any idea how to access USB, MMC and BLUETOOTH gateway device file systems using gnome vfs = API’s.

Any sample code in this regard will be of great = help.

 

Are only gnome vfs libraries sufficient to access = above mentioned device file systems on debian = Linux?

Or do we need to install some thing more on top of = gnome VFS?

 

Again any sample code will be of great = help.

 

 

 

Jitendra Moon

 

 

 

 

 

 

 

 

 

 

 

 

 

------=_NextPart_000_0007_01C3D2D1.81019BF0-- From ejk@ucsc.edu Fri Jan 2 17:47:02 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by mail.gnome.org (Postfix) with ESMTP id EF43B18448; Fri, 2 Jan 2004 17:47:01 -0500 (EST) Received: from [169.233.37.23] (k-d0789.resnet.ucsc.edu [169.233.37.23]) by ucsc.edu (8.10.1/8.10.1) with ESMTP id i02MhLx01991; Fri, 2 Jan 2004 14:43:23 -0800 (PST) Subject: Re: Suggestion for file type detection approach From: Edward Jay Kreps Reply-To: Suggestion.for.file.type.detection.approach@ucsc.edu To: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org, gnome-vfs-list@gnome.org Content-Type: text/plain Message-Id: <1073083582.3530.77.camel@whipple> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 14:46:22 -0800 Content-Transfer-Encoding: 7bit X-UCSC-CATS-MailScanner: Found to be clean X-UCSC-CATS-MailScanner-SpamCheck: Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: >Given the performance bottleneck imposed by sniffing, I suggest that it >is not used anymore in directory listing routines. It should be used >when the user tries to open an unknown file. Let's imagine this case: I don't think this is a good way of thinking about things. The questions are: 1. Is sniffing a good idea? 2. If so does it work correctly? 3. If (1) and (2), is it performing fast enough? I think others have argued persuasively that sniffing is a good idea since unix doesn't generally give file name suffixes to files (even though gnome does), and often files have incorrect suffixes. A number of people have said that there are instances where sniffing is not correctly determining the file type. If true, this is an excellent argument for fixing those cases, but not at all an argument for throwing away sniffing altogether. >From your benchmarking it is clear that (3) is a problem, and sniffing is taking too long. This is not an argument for getting rid of it though, just an argument for speeding it up. Someone suggested running it through a profiler, but I doubt that will be worthwhile--the problem is almost certainly the multiple disk accesses (your disk is having to seek for each file). As others have pointed out, a two pass technique. based on extension and then sniffing is also a bad idea since icons, etc would change in the case of a discrepancy. Sniffing is slow because it opens every file and reads some of it every time you open a given directory. If you want to make this fast, cache filetypes; now opening the huge mp3 folder is just a matter of reading a single cache file and sniffing those files with a modification time later than that of the cache file. Naturally this would only need to be done for those really huge directories, it would probably be a waste for directories with only a hundred files or fewer. I don't think we need to worry about which approach is ultimately going to perform faster. For a program like Nautilus either there is or is not a human-noticeable lag time; improving performance when there is no lag time is totally pointless. A number of people have used Windows as an example of why we don't need to sniff files; though there are a number of features in Windows worth copying this is definitely not one of them. I have worked on some commercial software and the number one frivolous bug report or unfixable user issue occurs when the user attempts to open a file that has an incorrect filename extension. People on this list have suggested that this is a user problem not a software problem (i.e. that the user was stupid and beyond help), but I can assure you that however obvious the connection between the hidden Windows filename extension and the error message that our program gave is to me and you, it was not obvious to a large number of otherwise very intelligent people who just weren't as knowledgeable about computers. People always think that the icon for a file is somehow part of the file (it makes sense if you don't think about it too hard), and so if a file has, say, a jpeg icon it doesn't occur to them that it is not a jpeg. -Jay From dionney@hotmail.com Fri Jan 2 19:58:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from dionney.dyndns.org (modemcable253.38-203-24.mc.videotron.ca [24.203.38.253]) by mail.gnome.org (Postfix) with ESMTP id B0854182E2; Fri, 2 Jan 2004 19:58:08 -0500 (EST) Received: from [127.0.0.1] (dionney.dyndns.org [127.0.0.1]) by dionney.dyndns.org (Postfix) with ESMTP id F2F9CFD65; Fri, 2 Jan 2004 19:57:59 -0500 (EST) Subject: Re: Suggestion for file type detection approach From: Yves Dionne To: gnome-vfs-list@gnome.org Cc: nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1072403221.945.61.camel@hermes.intra.gs2.com.br> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> Content-Type: multipart/mixed; boundary="=-uazmxkOo5iyZC9kUE0ez" Message-Id: <1073091476.23189.12.camel@dionney.dyndns.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 02 Jan 2004 19:57:58 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-uazmxkOo5iyZC9kUE0ez Content-Type: text/plain; charset= Content-Transfer-Encoding: 8bit On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > Why not support recording the mime-type of a file as meta-data (EA) on > > filesystems that support it (every one of them at this point?). It > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > to clearly be the right way to do it. If GNOME VFS supported it then > > it seems it would be easy to implement for alot of applications. > > > > I agree with you, but while we must provide a quick solution, EA (and > the attributes themselves) must be standardized cross-unix and > cross-desktop. This will take some time to mature, since the mechanisms > for sending files through the Internet (between computers, in general) > must mature to support EA. I never used Apple operating systems, but it > looks like they have such a mechanism. Nothing that a tar with EA > support could not do. > > GNOME must provide room today to support state-of-the-art technologies > in the future, but must at the same time provide solutions to today's > users using today's technologies. > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. I thought this could be fun, so hacked gnome-vfs to save the mime type on a EA named "mime_type". When trying to find the mime type for the file, gnome-vfs will first check if this EA exists. If so, use that for the mime type. If not, determine the mime type as usual and save it. It works only for local files. If you don't have permission to change the file, the EA will not be saved. And you need a file system which support EA, of course. I tested it with ext3. Might work with others too. This is a hack, just an exercise to see if it could be beneficial. I did this just for fun. I did not try to follow coding standards, I have no intention of maintaining this patch. Although I might try to hack nautilus to allow changing the mime type (as recorded in the EA). The following patch is against gnome-vfs-2.4.1 as found in Fedora. I attach also a modified SPEC file, just in case someone wants to build it. --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs-2.4.1-attr.patch Content-Type: text/x-patch; name=gnome-vfs-2.4.1-attr.patch; charset= Content-Transfer-Encoding: 7bit diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h gnome-vfs-2.4.1/acconfig.h --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/acconfig.h 2003-09-27 11:42:49.000000000 -0400 +++ gnome-vfs-2.4.1/acconfig.h 2004-01-02 17:11:36.665008680 -0500 @@ -15,6 +15,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in gnome-vfs-2.4.1/config.h.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/config.h.in 2003-09-01 14:32:48.000000000 -0400 +++ gnome-vfs-2.4.1/config.h.in 2004-01-02 17:11:36.667008376 -0500 @@ -16,6 +16,7 @@ #undef ENABLE_PROFILER #undef HAVE_OPENSSL #undef HAVE_FAM +#undef HAVE_ATTR #undef HAVE_OFF64_T #undef GETTEXT_PACKAGE diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in gnome-vfs-2.4.1/configure.in --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/configure.in 2003-10-12 06:51:55.000000000 -0400 +++ gnome-vfs-2.4.1/configure.in 2004-01-02 17:11:36.671007768 -0500 @@ -482,6 +482,22 @@ +dnl *********************** +dnl *** Checks for ATTR *** +dnl *********************** + +ATTR_MISSING_WARNING="Gnome-vfs depends on ATTR" +ATTR_LIBS= +AC_CHECK_LIB(attr, attr_getf, + [AC_CHECK_HEADERS(attr/attributes.h, + [AC_DEFINE(HAVE_ATTR) + ATTR_LIBS="-lattr"], + AC_MSG_WARN(*** ATTR support will not be built (header files not found) $ATTR_MISSING_WARNING ***))], + AC_MSG_WARN(*** ATTR support will not be built (ATTR library not found) $ATTR_MISSING_WARNING ***)) +AC_SUBST(ATTR_LIBS) + + + dnl ************************** dnl *** Checks for gtk-doc *** dnl ************************** diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2003-09-27 11:42:51.000000000 -0400 +++ gnome-vfs-2.4.1/libgnomevfs/gnome-vfs-mime.c 2004-01-02 17:15:50.041489600 -0500 @@ -39,6 +39,9 @@ #include #include #include +#ifdef HAVE_ATTR +#include +#endif static gboolean module_inited = FALSE; @@ -80,6 +83,40 @@ #endif /* G_LOCK_DEFINE_STATIC */ +#ifdef HAVE_ATTR +static GList *mime_attr = NULL; + +static const char * +get_mime_from_ea (FILE *file) +{ + char * mime_type = NULL; + char * buffer = g_alloca (256+1); + GList * p; + int len = 256; + + if (attr_getf (fileno (file), "mime_type", buffer, &len, 0) == 0) { + buffer[len] = 0; + G_LOCK (mime_mutex); + p = g_list_find_custom (mime_attr, buffer, g_ascii_strcasecmp); + if (p != NULL) { + mime_type = p->data; + } else { + mime_type = g_strdup (buffer); + mime_attr = g_list_insert_sorted (mime_attr, mime_type, g_ascii_strcasecmp); + } + G_UNLOCK (mime_mutex); + } + return mime_type; +} + +static void +set_mime_from_ea (FILE *file, const char *mime_type) +{ + int len = strlen (mime_type); + + attr_setf (fileno (file), "mime_type", mime_type, len, 0); +} +#endif static char * get_priority (char *def, int *priority) @@ -337,6 +374,13 @@ g_list_free (mime_regexs [i]); mime_regexs [i] = NULL; } +#ifdef HAVE_ATTR + for (p = mime_attr; p != NULL; p = p->next) { + g_free (p->data); + } + g_list_free (mime_attr); + mime_attr = NULL; +#endif } static void @@ -714,11 +758,22 @@ } if (file != NULL) { +#if HAVE_ATTR + result = get_mime_from_ea (file); + if (result == NULL) + { +#endif buffer = _gnome_vfs_mime_sniff_buffer_new_generic (file_seek_binder, file_read_binder, file); result = _gnome_vfs_get_mime_type_internal (buffer, path); gnome_vfs_mime_sniff_buffer_free (buffer); +#ifdef HAVE_ATTR + if (result != NULL) { + set_mime_from_ea (file, result); + } + } +#endif fclose (file); } else { result = _gnome_vfs_get_mime_type_internal (NULL, path); diff -ur /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am gnome-vfs-2.4.1/libgnomevfs/Makefile.am --- /home/dionney/rpm/BUILD/gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:10:48.860276104 -0500 +++ gnome-vfs-2.4.1/libgnomevfs/Makefile.am 2004-01-02 17:11:36.679006552 -0500 @@ -37,6 +37,7 @@ libgnomevfs_2_la_LIBADD = \ $(LIBGNOMEVFS_LIBS) \ + $(ATTR_LIBS) \ $(NULL) libgnomevfs_2_la_LDFLAGS = \ --=-uazmxkOo5iyZC9kUE0ez Content-Disposition: attachment; filename=gnome-vfs2.spec Content-Type: text/plain; name=gnome-vfs2.spec; charset= Content-Transfer-Encoding: 8bit %define libbonobo_version 2.2.0 %define gconf2_version 1.2.0 %define gtkdoc_version 0.9 %define gnome_mime_data_version 2.0.0-11 %define redhat_menus_version 0.30 %define po_package gnome-vfs-2.0 Summary: The GNOME virtual file-system libraries. Name: gnome-vfs2 Version: 2.4.1 Release: 1 License: LGPL Group: System Environment/Libraries Source: gnome-vfs-%{version}.tar.bz2 Source2: vfolder-desktop-method.c Source3: desktop-method.c URL: http://www.gnome.org/ BuildRoot: %{_tmppath}/%{name}-%{version}-root Requires: gnome-mime-data >= %{gnome_mime_data_version} Requires: redhat-menus >= %{redhat_menus_version} BuildRequires: libbonobo-devel >= %{libbonobo_version} BuildRequires: GConf2-devel >= %{gconf2_version} BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: bonobo-activation-devel, glib2-devel, libxml2-devel, zlib-devel BuildRequires: popt, bzip2-devel, ORBit2-devel, XFree86-devel, openjade BuildRequires: pkgconfig BuildRequires: gnome-mime-data >= %{gnome_mime_data_version} BuildRequires: /usr/bin/automake-1.4 BuildRequires: gtk-doc >= %{gtkdoc_version} Prereq: GConf2 >= %{gconf2_version} Patch1: gnome-vfs-1.9.4.91-docdir.patch Patch2: gnome-vfs-2.1.3-moved-menu-files.patch Patch3: gnome-vfs-2.0.4-onlyshowin.patch Patch5: gnome-vfs-1.9.16-moved-menu-files.patch Patch6: gnome-vfs-2.0.1-only-show-in.patch Patch7: gnome-vfs-2.3.7-modules-conf.patch Patch8: gnome-vfs-2.0.2-newstat.patch Patch9: gnome-vfs-2.0.2-read-only.patch ## this is the automake-requiring patch Patch10: gnome-vfs-2.1.6-old-modules.patch Patch11: gnome-vfs-2.1.6-network-uri.patch Patch12: gnome-vfs-2.1.6-never-show-if-empty.patch Patch13: gnome-vfs-2.1.6-hide-with-empty-subfolders.patch Patch14: gnome-vfs-2.1.6-no-private-methods.patch Patch15: gnome-vfs-2.2.0-vfolder-hacks.patch Patch16: gnome-vfs-2.4.1-attr.patch %description GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for file systems, http, ftp, and others. It provides a URI-based API, backend supporting asynchronous file operations, a MIME type manipulation library, and other features. %package devel Summary: Libraries and include files for developing GNOME VFS applications. Group: Development/Libraries Requires: %{name} = %{version} Requires: GConf2-devel >= %{gconf2_version} Requires: libbonobo-devel >= %{libbonobo_version} Conflicts: bonobo-devel < 1.0.8 Conflicts: gnome-vfs-devel < 1.0.2 %description devel This package provides the necessary development libraries for writing GNOME VFS modules and applications that use the GNOME VFS APIs. %prep %setup -q -n gnome-vfs-%{version} cp -f %{SOURCE2} modules cp -f %{SOURCE3} modules # Patch1: gnome-vfs-1.9.4.91-docdir.patch modifies doc/Makefile.am #%patch1 -p1 -b .docdir (cd modules && cp default-modules.conf default-modules.conf.with-menu-editing) ## clean out the methods that don't work with our setup DMC=modules/default-modules.conf.with-menu-editing perl -pi -e 's/all-applications:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/all-preferences:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/favorites:\s+libvfolder-desktop.so//g' $DMC perl -pi -e 's/network:\s+libvfolder-desktop.so//g' $DMC ## these two should actually work ## perl -pi -e 's/applications-all-users:\s+libvfolder-desktop.so//g' $DMC ## perl -pi -e 's/preferences-all-users:\s+libvfolder-desktop.so//g' $DMC ## these are now in the vfolder-hacks patch #%patch2 -p1 -b .moved-menu-files #%patch3 -p0 -b .onlyshowin %patch5 -p1 -b .moved-menu-files %patch6 -p1 -b .only-show-in %patch7 -p1 -b .modules-conf %patch8 -p1 -b .newstat %patch9 -p1 -b .read-only %patch10 -p1 -b .old-modules %patch11 -p1 -b .network-uri %patch12 -p1 -b .never-show-if-empty %patch13 -p1 -b .hide-with-empty-subfolders %patch14 -p1 -b .no-private-methods %patch15 -p0 -b .vfolder-hacks %patch16 -p1 -b .attr %build # needed for patch10 (changing makefile to old vfolder backend) automake-1.4 # needed for patch16 (changing configure.in for EA) autoconf if pkg-config openssl ; then CPPFLAGS=`pkg-config --cflags openssl`; export CPPFLAGS LDFLAGS=`pkg-config --libs-only-L openssl`; export LDFLAGS fi %configure export tagname=CC make LIBTOOL=/usr/bin/libtool %install rm -fr %{buildroot} export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 export tagname=CC %makeinstall LIBTOOL=/usr/bin/libtool unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL rm -f $RPM_BUILD_ROOT%{_libdir}/gnome-vfs-2.0/modules/lib*.a rm -f $RPM_BUILD_ROOT%{_libdir}/*.la rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info rm -f $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default ## why, dear god, why? rm -f $RPM_BUILD_ROOT%{_datadir}/aclocal/gob2.m4 install -m 644 modules/default-modules.conf.with-menu-editing $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/ ## Remove this line and update file list to revert to ## no-menu-editing-by-default # (cd $RPM_BUILD_ROOT%{_sysconfdir}/gnome-vfs-2.0/modules/; mv default-modules.conf default-modules.conf.without-menu-editing; mv default-modules.conf.with-menu-editing default-modules.conf) rm -f $RPM_BUILD_ROOT%{_libdir}/bonobo/monikers/*.{a,la} %find_lang %{po_package} %clean rm -fr %{buildroot} %post export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` SCHEMAS="system_http_proxy.schemas" for S in $SCHEMAS; do gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/$S > /dev/null done /sbin/ldconfig %postun -p /sbin/ldconfig %files -f %{po_package}.lang %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README %dir %{_sysconfdir}/gnome-vfs-2.0 %dir %{_sysconfdir}/gnome-vfs-2.0/modules #%dir %{_sysconfdir}/gnome-vfs-2.0/vfolders %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf %config %{_sysconfdir}/gnome-vfs-2.0/modules/*.conf.with-menu-editing ## we aren't really using the .vfolder-info config files, ## so installing them is a little misleading. ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info ## %config %{_sysconfdir}/gnome-vfs-2.0/vfolders/*.vfolder-info-default %{_bindir}/* %{_libdir}/*.so.* %{_libdir}/gnome-vfs-2.0/modules %dir %{_libdir}/gnome-vfs-2.0 %{_libdir}/bonobo %{_libdir}/vfs %{_sysconfdir}/gconf/schemas/* ## conflicts with gnome-vfs 1, ignore for now ## %{_datadir}/man/man5/* %files devel %defattr(-, root, root) %{_libdir}/lib*.a %{_libdir}/lib*.so %{_libdir}/pkgconfig/* %{_libdir}/gnome-vfs-2.0/include/*.h %{_includedir}/* %{_datadir}/gtk-doc %changelog * Wed Oct 15 2003 Alexander Larsson 2.4.1-1 - Update to 2.4.1, fixes bug #107130 * Tue Sep 9 2003 Alexander Larsson 2.4.0-1 - update to 2.4.0 * Tue Sep 2 2003 Alexander Larsson 2.3.90-1 - update to 2.3.90 * Mon Aug 25 2003 Alexander Larsson 2.3.8-1 - update to 2.3.8 * Mon Aug 11 2003 Alexander Larsson 2.3.7-1 - update for gnome 2.3 * Tue Jul 22 2003 Nalin Dahyabhai 2.2.5-3 - rebuild, setting tagname to CC * Tue Jul 8 2003 Alexander Larsson 2.2.5-2.E - Rebuild * Wed Jun 04 2003 Elliot Lee - rebuilt * Tue May 27 2003 Alexander Larsson 2.2.5-1 - Update to 2.2.5 * Mon Mar 31 2003 Alexander Larsson 2.2.4-1 - Update to 2.2.4 * Mon Feb 24 2003 Elliot Lee - debuginfo rebuild * Mon Feb 24 2003 Alexander Larsson 2.2.2-3 - Added patch to fix smb crash (#84982) * Mon Feb 24 2003 Alexander Larsson 2.2.2-2 - Add patch to fix notify race (#84668) * Wed Feb 12 2003 Alexander Larsson 2.2.2-1 - 2.2.2, fixes bad memleak (#83791) * Tue Feb 11 2003 Havoc Pennington 2.2.1-3 - kill menu editing again, it was very very broken * Mon Feb 10 2003 Bill Nottingham 2.2.1-2 - fix file list (#68226) - prereq GConf2 * Mon Feb 10 2003 Alexander Larsson 2.2.1-1 - Update to 2.2.1. fixes gnome-theme-manager hang * Thu Feb 6 2003 Havoc Pennington 2.2.0-7 - move to menu editing modules.conf by default, we'll see if it works * Tue Jan 28 2003 Matt Wilson 2.2.0-6 - use LIBTOOL=/usr/bin/libtool * Mon Jan 27 2003 Havoc Pennington - it would help to *install* the stupid menu edit conf file - update the vfolder-hacks patch with some fixes * Fri Jan 24 2003 Havoc Pennington - hack up editable vfolder backend to maybe work (still not the default config file) * Wed Jan 22 2003 Havoc Pennington - include a non-default config file to use new vfolder method - build the new vfolder method * Wed Jan 22 2003 Tim Powers - rebuilt * Tue Jan 21 2003 Alexander Larsson - Update to 2.2.0 * Mon Jan 13 2003 Havoc Pennington - variation on the subfolders hack to try to fix it * Sat Jan 11 2003 Havoc Pennington - fix bug where empty folders with empty subfolders would still be visible. * Sat Jan 11 2003 Havoc Pennington - finish adapting desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - adapt desktop-method.c to underscore-prefixing action * Sat Jan 11 2003 Havoc Pennington - hardcode , it's stupid to ever override this. * Sat Jan 11 2003 Havoc Pennington - make network:/// use libdesktop.so, and modify libdesktop.so to support it * Sat Jan 11 2003 Havoc Pennington - Revert to George's vfolder backend from gnome-vfs-2.0.2 or so - put back libdesktop.so - don't build the new vfolder backend * Wed Jan 8 2003 Alexander Larsson 2.1.6-2 - Removed __libdir fix that was fixed upstream * Wed Jan 8 2003 Alexander Larsson 2.1.6-1 - Update to 2.1.6 * Tue Jan 7 2003 Nalin Dahyabhai 2.1.5-3 - rebuild * Mon Dec 16 2002 Tim Powers 2.1.5-2 - rebuild * Mon Dec 16 2002 Alexander Larsson 2.1.5-1 - Update to 2.1.5 * Thu Dec 12 2002 Nalin Dahyabhai - use OpenSSL's pkg-config information, if available * Wed Dec 4 2002 Havoc Pennington - 2.1.3.1 * Sun Nov 10 2002 Havoc Pennington - 2.1.3 - update moved-menu-files patch * Wed Oct 23 2002 Havoc Pennington - add patch for OnlyShowIn support - use plain menu files for .vfolder-info-default - don't install unused vfolder-info files * Tue Oct 8 2002 Havoc Pennington - require new gnome-mime-data in proper libdir - 2.0.4 - drop most patches as they are now upstream or don't apply to new vfolder code * Fri Aug 30 2002 Owen Taylor - Backport a gnome-vfs locking fix from CVS (Hopefully fixes #71419) * Fri Aug 23 2002 Havoc Pennington - make vfolder method read-only #72208 * Mon Aug 19 2002 Jonathan Blandford - notice when new files are installed * Tue Aug 13 2002 Havoc Pennington - don't include pointless .a files * Fri Aug 2 2002 Havoc Pennington - 2.0.2 - use vfolders for system-settings and server-settings * Tue Jul 16 2002 Havoc Pennington - fix OnlyShowIn * Tue Jun 25 2002 Owen Taylor - Version 2.0.1, fix missing po files * Sun Jun 16 2002 Havoc Pennington - 2.0.0 - put schema files in file list, and install them - put libdir/vfs in file list * Tue Jun 11 2002 Havoc Pennington - rebuild in different environment * Tue Jun 11 2002 Havoc Pennington - look for menus in redhat-menus * Fri Jun 07 2002 Havoc Pennington - rebuild in different environment * Wed Jun 5 2002 Havoc Pennington - 1.9.16 * Sun May 26 2002 Tim Powers - automated rebuild * Mon May 20 2002 Havoc Pennington - rebuild in different environment * Mon May 20 2002 Havoc Pennington - 1.9.15 - comment out docdir patch for now * Fri May 3 2002 Havoc Pennington - 1.9.14 * Thu Apr 4 2002 Jeremy Katz - 1.9.11 - update file list * Thu Feb 14 2002 Havoc Pennington - 1.9.7 * Thu Jan 31 2002 Owen Taylor - Fix location of installed docs not to conflict with gnome-vfs1 * Wed Jan 30 2002 Owen Taylor - Rebuild with new libs * Wed Jan 09 2002 Tim Powers - automated rebuild * Thu Jan 3 2002 Havoc Pennington - 1.0.4.91 snap * Mon Nov 26 2001 Havoc Pennington - 1.9.4.90 snap - require gnome-mime-data * Sun Oct 28 2001 Havoc Pennington - new snap, rebuild for glib 1.3.10 * Fri Oct 5 2001 Havoc Pennington - cvs snap * Fri Sep 21 2001 Havoc Pennington - rebuild cvs snap with changes merged upstream - fix a requires - fix up requires/buildrequires a bit * Tue Sep 18 2001 Havoc Pennington - initial gnome-vfs2 build, remove all patches - change config files not to be noreplace * Mon Aug 27 2001 Havoc Pennington - Add po files from sources.redhat.com * Mon Aug 20 2001 Havoc Pennington - fix #51864 (Gimp can't handle file: URIs) * Mon Aug 20 2001 Alexander Larsson 1.0.1-15 - Moved gnome-conf and pkgconfig files to the devel package - Fixes SHOULD-FIX bug #49795 * Mon Aug 6 2001 Alexander Larsson 1.0.1-14 - Added a patch that fixed AbiWord mimetype handling. * Fri Jul 27 2001 Jonathan Blandford - Add .desktop file sniffing * Tue Jul 24 2001 Havoc Pennington - don't do the giant trash scan thing; did not play nice with NFS. * Tue Jul 24 2001 Havoc Pennington - fix desktop-file.conf file * Tue Jul 24 2001 Havoc Pennington - change some URI scheme names * Fri Jul 20 2001 Alexander Larsson - Add pkgconfig and gnome-libs-devel build reqs. - Remove dependency on gnome-vfs-devel by doing some - CPPFLAGS and LDFLAGS magic * Wed Jul 11 2001 Havoc Pennington - add missing directories * Tue Jul 10 2001 Havoc Pennington - fix a segv - change which dirs the desktop VFS module points to * Sun Jul 08 2001 Havoc Pennington - add desktop VFS module hack * Fri Jul 6 2001 Trond Eivind Glomsrød - Remove Distribution and Vendor - Make the config files noreplace - Move .so links to devel subpackage - langify - Add BuildRequires - Don't mess with /etc/ld.so.conf - Use %%{_tmppath} - s/Copyright/License/ * Sun Jun 24 2001 Elliot Lee - Bump release + rebuild. * Wed May 9 2001 Jonathan Blandford - New Version. * Tue Apr 17 2001 Jonathan Blandford - New Version. - clean up spec file some. * Mon Feb 19 2001 Gregory Leblanc - fix paths and macros * Tue Feb 22 2000 Ross Golder - Integrate into source tree --=-uazmxkOo5iyZC9kUE0ez-- From awilliam@whitemice.org Sun Jan 4 08:13:09 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mail.gnome.org (Postfix) with ESMTP id 7965F183D4; Sun, 4 Jan 2004 08:13:09 -0500 (EST) Received: from adsl-68-72-14-103.dsl.klmzmi.ameritech.net ([68.72.14.103] helo=estate1.whitemice.org) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ad840-0004TY-00; Sun, 04 Jan 2004 05:13:04 -0800 Received: from estate2.whitemice.org (estate2.whitemice.org [192.168.3.245]) by estate1.whitemice.org (8.12.5/8.12.5) with ESMTP id i04DGaAC007033; Sun, 4 Jan 2004 08:16:36 -0500 Subject: Re: Suggestion for file type detection approach From: Adam Williams To: Yves Dionne Cc: gnome-vfs-list@gnome.org, nautilus-list@gnome.org, gnome-list@gnome.org, gnome-devel-list@gnome.org In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain Message-Id: <1073221987.5722.64.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 08:13:07 -0500 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > Indeed, but it's all we have for now. Now = 2.6. > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. Yes, please! I mentioned EA awhile ago to no response; sniff, look at extensions, whatever - and keep your results. Even better if applications that created files put the EA tags in themselves. This is so obviously the right solution - Mac OS has been doing this forever, and Winblows is starting to make real use of EA as well. EA follow the file when copied, moved, etc... You could even store a thumbnail in EA and not generate one every time or cache it somewhere annoying like ".nautilus". > It works only for local files. Not sure this is true. The EA on NTFS can be accessed by CIFS calls, and NFSv4 at least supports extended attributes. But maybe niether are ture on Linux at this point. > If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. Works with ext3, XFS, and JFS (at least). > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. Excellent. From dobey@free.fr Sun Jan 4 12:19:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id 1926718685 for ; Sun, 4 Jan 2004 12:19:14 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdBtq-0007Aa-0W; Sun, 04 Jan 2004 12:18:50 -0500 Subject: Re: FUD about security and file extensions (was Re: Why file content sniffing sucks) From: Rodney Dawes To: "Jason A. Pfeil" Cc: Charles Goodwin , Fabio Gomes , Colin Walters , gnome-vfs-list@gnome.org In-Reply-To: References: <1072278440.1486.125.camel@hermes.intra.gs2.com.br> <20031224154241.GK1205@lazarus> <1072281561.4971.11.camel@firebrand> <1072283138.1087.26.camel@discomachinegun.prettypeople.org> <1072291008.15811.3.camel@nexus.verbum.private> <1072401563.945.33.camel@hermes.intra.gs2.com.br> <1072403078.27575.20.camel@mightymax.charlietech.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1073236729.26544.144.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:18:49 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On H=C3=ABn , 2003-12-29 at 10:21, Jason A. Pfeil wrote: > On Fri, 26 Dec 2003, Charles Goodwin wrote: > [...snip...] > > Yes, file sniffing is slow. So implement it in a way that does not > > affect the user. Last time I used Nautilus, I could scroll up and down > > and jump between folders without extra pause, whilst Nautilus updates > > itself in the background. So what is the issue? It only updates what > > is in immediate view (as I recall) so you just scroll to your desired > > file and, if necessary, wait the 2s for it to be detected. >=20 > I think that this is how it was supposed to be implemented, but I don't > believe that this implementation has actually been done. As a quick test= , > open /usr/bin in nautilus. On the box I am using to write this, /usr/bin > has 2,124 files in it. Nautilus took about 10 seconds to load the > contents of that directory. In comparison, use a shell and cd to /usr/bi= n. > Then, type the command: >=20 > echo * >=20 > and see how much faster that returns. echo * returned instantly on my bo= x. > If you want, you can do the echo * method first just so you can convince > yourself that nautilus is not caching things for the shell. And how do I convince myself that echo is doing all of the same activities that nautilus is? Doing a simple "echo *" has substantially less traffic to the X server. It doesn't tell you mime types, modification times, number of files in the child directories, or anything extra about the files. Hell, it doesn't even put the filenames on new lines. If you want to make a comparison like this for mime types, then either compare file and test-mime from the gnome-vfs tests/ directory, on a terminal, while redirecting STDIN and STDOUT to /dev/null, so that terminal X traffic and rendering speed doesn't come in to play. Then you should see that it is not the mime type detection that is slow. The gnome-vfs mime test and file take about the same time to complete. It took less than half a second for gnome-vfs to get the mime types of over 619 files on my system. > Also, when nautilus is opening the directory, take note of the extreme di= sk > churning you hear and note its absence when using the echo * command. FY= I, > the hardware I ran this on is a 1.8GHz P4 with 1GB RAM and U160 SCSI disk > on an Adaptec 7892A controller. Hardly pokey by any standards. Yes. The "echo *" command doesn't open any files at all. It's all done in the command line shell. It simply expands * to all filenames in the current directory, and spits them out on STDOUT. It is not doing anything complex at all. Maybe you should fix The GIMP to use "echo *" when it starts up. It takes a long time to load all those plug-ins. > If we want the average user to use Linux over Windows, we have to have a > system that is competitive not only in security, but also in speed. Whil= e > nautilus has improved greatly over the years, it is still *far* behind > explorer in speed and this file-type identification issue is a prime reas= on. s/Linux/GNOME/ Linux in general is as fast as, if not faster than, Windows. Nautilus is also just as fast as Explorer. Saying X is faster than Y because Y is doing more is ignorant. If Nautilus is slower than Explorer for you, it is a configuration issue, not an issue of how it detects the mime types. You really should spend your time profiling the GNOME libraries and Nautilus if you think your statement is true. Stating your opinion of what is wrong with it won't get it fixed. Proving where the speed bottlenecks are with profiling data and real comparisons with more constants than the hardware it was run on, will be much more useful. > > If Nautilus is wrongly detecting a file type it is a _bug_ and should b= e > > dealt with as such. It is nothing to do with the system used by > > Nautilus. Detection of type by file extension is far more error prone > > and relies much more on correctness of user input which is an > > unreasonable expection on lay users. >=20 > I dispute this notion. Proper training of users (not unreasonable) with = the > help of applications automatically setting file-types will go a long way > towards having good input from users. You can't claim a dispute and then agree. Reasonable training and application assistance will go a long way, yes. However, we shouldn't be relying on user-training. We should be writing applications that help the user to learn on their own. Psychology is a very important aspect to usability. Having a user do something on their own instills pride. Don't you feel like doing more when you do something yourself, as opposed to having to spend $1200 to learn to write a basic web page? Our applications should be smart enough to let the users know what they are doing, and if what they are doing is correct. Also, people migrating from Windows or Mac OS have a bit of training. They generally know enough about icon/label->action associations and similar, that they can figure out things fairly quickly. > [...snip...] > > > The bugs present in Micros~1 Windows are not due to file type detecti= on > > > by suffix.=20 > >=20 > > Wrong, they are. By due nature of the ridiculous method, people > > associate .jpg files or .gif files as images. This introduces a proble= m > > with visual association. > > Somebody gets an email with an attachment such as 'pretty.jpg.exe' or > > 'sexy.gif.pl' and they open it up. Yes, this is due to file type > > detection by suffix because you are subconciously causing people to > > recognise file types by file suffix and hence they can be easily > > mislead. > However, in this type of example, the extensions for both of these files > are .exe and .pl, respectively. Therefore there is no ambiguity since a > file ending in .exe is not a file ending in .jpg and a file ending in .pl > is not a file ending in .gif. The only time that this can cause a proble= m > is when the system *hides* the extension like Windows does. This is a > badly contrived example. No. It goes beyond hiding the extension. Many versions of the file system also only support a maximum of one period in the filename. This really causes problems. The suffix detection also plays a major role, but it is not the only contributing factor. > [...snip...] > >=20 > > One goal of Gnome is to make Free Software desktops a global reality (a= s > > if it already isn't). Introducing notions that add to the confusion > > just to save a few cpu cycles and/or to make things look snappier > > on-the-surface is no way to achieve that goal; unless you want a buggy, > > insecure system but that niche is already well filled. >=20 > Or unless you want to have widespread use. Unfortunately, the average us= er > expects a computer to be fast. By coupling the file extension method wit= h > a type-match check method when the file is opened using nautilus, you get > the best of both worlds. I fail to see the objection. It's just as fast > as the way Windows does it, and it's just as secure as the current way > that nautilus does it. Contriving a conflict is counter-productive. We do have widespread use. Not as widespread as, say, Windows, but still, we have many a user. That user-base is only increasing, as well. The average user does not expect their computer to be as fast as you claim. The average user, uses Windows. Windows is by no means fast. Using both methods of file type detection will gain us nothing. In fact, we already do use both methods. The suffix checking is generally a fall-back method, though. Read the code. It's right there in plain sight. Contriving conflicts is indeed counter-productive. Please stop. :) > > I wish this pointless discussion would go away. It's clogging up my > > inbox. Really, there's some damn clever guys hacking Gnome and this >=20 > You can always unsubscribe to the list or request to get messages in a > digest. However, terminating a discussion because it bores you or is a > minor inconvenience to you is not the right approach. > [...snip...] It's not only an annoyance to him. These mails have been going to far more lists than they should have, if any at all. Continuing a thread simply so that it does go on, is also not the right approach. -- dobey From dobey@free.fr Sun Jan 4 12:47:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from free.fr (h00062581ff98.ne.client2.attbi.com [24.34.20.55]) by mail.gnome.org (Postfix) with ESMTP id AFA641853E for ; Sun, 4 Jan 2004 12:47:52 -0500 (EST) Received: from dobey by free.fr with local (Exim 4.22) id 1AdCLf-0007BI-Ij; Sun, 04 Jan 2004 12:47:35 -0500 Subject: Re: Suggestion for file type detection approach From: Rodney Dawes To: ejk@ucsc.edu Cc: gnome-vfs-list@gnome.org In-Reply-To: <1073083582.3530.77.camel@whipple> References: <1073083582.3530.77.camel@whipple> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1073238454.26541.173.camel@blackbox.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Jan 2004 12:47:35 -0500 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > >Given the performance bottleneck imposed by sniffing, I suggest that it > >is not used anymore in directory listing routines. It should be used > >when the user tries to open an unknown file. Let's imagine this case: > > I don't think this is a good way of thinking about things. The questions are: > 1. Is sniffing a good idea? > 2. If so does it work correctly? > 3. If (1) and (2), is it performing fast enough? > > I think others have argued persuasively that sniffing is a good idea > since unix doesn't generally give file name suffixes to files (even > though gnome does), and often files have incorrect suffixes. > > A number of people have said that there are instances where sniffing is > not correctly determining the file type. If true, this is an excellent > argument for fixing those cases, but not at all an argument for throwing > away sniffing altogether. I've only seen one person say that. And as I understand, no real information was provided. Only a comment of "it broke on this one file." But yes, it is a good argument for improving the system, not removing the core functionality. > >From your benchmarking it is clear that (3) is a problem, and sniffing > is taking too long. This is not an argument for getting rid of it > though, just an argument for speeding it up. Someone suggested running > it through a profiler, but I doubt that will be worthwhile--the problem > is almost certainly the multiple disk accesses (your disk is having to > seek for each file). As others have pointed out, a two pass technique. > based on extension and then sniffing is also a bad idea since icons, etc > would change in the case of a discrepancy. It is not clear that 3 is a problem. It is only probable that 3 may be an issue on a certain machine with a certain configuration. I guarantee that the sniffing is not the bottleneck. Running it through a profiler will be much more worthwhile than sending mail to a list saying "it's slow." And yes, I am the one that suggested profiling. The disk i/o is most certainly not the bottleneck. Given the speed of hard disks today, seek time is not an issue. Even if it took the 12ms maximum seek time on a newer model hard disk, and you were loading a directory with 1000 files in it, that is only 12 seconds. Given the size of cache on newer hard disks, and the fact that people generally open up the same few folders, rather than opening / and traversing the tree looking for things, or opening odd folders randomly, I would guess that the maximum seek time would be around 3-4 milliseconds. It is much more likely some other problem that is specific to something Nautilus is doing to display the list of files. I also suggested other things than profiling, such as writing specific benchmarks to compare test-mime from gnome-vfs and file, which would be much more useful than saying "Nautilus must be slow because echo * is instantaneous" or other such nonsense. Real benchmarks are much more reliable than "it seemed slow" or "I used a stopwatch", as human error and perception can misinterpret how long it actually took to do something. > Sniffing is slow because it opens every file and reads some of it every > time you open a given directory. If you want to make this fast, cache > filetypes; now opening the huge mp3 folder is just a matter of reading a > single cache file and sniffing those files with a modification time > later than that of the cache file. Naturally this would only need to be > done for those really huge directories, it would probably be a waste for > directories with only a hundred files or fewer. Sniffing is not slow because it opens every file and reads some of it. Though, it may be if you end up opening network mounts, since all of the stat()s are network-bound, which is much slower than local hard disk access. There can surely be improvements in speed for network-bound i/o in gnome-vfs, and improvements in file type detection as well, since most all web server installations on the Internet, are broken. They also generally use filename extensions to determine what to send for the Content-Type: header. This is what gnome-vfs uses currently. > I don't think we need to worry about which approach is ultimately going > to perform faster. For a program like Nautilus either there is or is not > a human-noticeable lag time; improving performance when there is no lag > time is totally pointless. Aye. In general, the speed issues have nothing to do with the way the mime type is detected. Any claims that one is substantially faster than the other, is generally due to misperception. The real issues seem to generally be at a lower level, or totally unrelated, such as the issues with some of the thumbnailers. > A number of people have used Windows as an example of why we don't need > to sniff files; though there are a number of features in Windows worth > copying this is definitely not one of them. I have worked on some > commercial software and the number one frivolous bug report or unfixable > user issue occurs when the user attempts to open a file that has an > incorrect filename extension. People on this list have suggested that > this is a user problem not a software problem (i.e. that the user was > stupid and beyond help), but I can assure you that however obvious the > connection between the hidden Windows filename extension and the error > message that our program gave is to me and you, it was not obvious to a > large number of otherwise very intelligent people who just weren't as > knowledgeable about computers. People always think that the icon for a > file is somehow part of the file (it makes sense if you don't think > about it too hard), and so if a file has, say, a jpeg icon it doesn't > occur to them that it is not a jpeg. Indeed. -- dobey From david@davemalcolm.demon.co.uk Sun Jan 4 19:21:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by mail.gnome.org (Postfix) with ESMTP id 89DF618497; Sun, 4 Jan 2004 19:21:39 -0500 (EST) Received: from davemalcolm.demon.co.uk ([80.177.172.172] helo=[192.168.0.3]) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1AdIV0-000C9Z-0Y; Mon, 05 Jan 2004 00:21:38 +0000 Subject: Re: Suggestion for file type detection approach From: Dave Malcolm To: Yves Dionne Cc: Gnome VFS List , Nautilus List , gnome-list@gnome.org, "gnome-devel-list@gnome.org" In-Reply-To: <1073091476.23189.12.camel@dionney.dyndns.org> References: <1072374536.9060.136.camel@hermes.intra.gs2.com.br> <1072400310.5409.2.camel@localhost.localdomain> <1072403221.945.61.camel@hermes.intra.gs2.com.br> <1073091476.23189.12.camel@dionney.dyndns.org> Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1073262381.32307.3969.camel@shirehorse1> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Jan 2004 00:26:22 +0000 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sat, 2004-01-03 at 00:57, Yves Dionne wrote: > On Thu, 2003-12-25 at 20:47, Fabio Gomes wrote: > > Em Qui, 2003-12-25 às 21:58, Adam Williams escreveu: > > > > > Why not support recording the mime-type of a file as meta-data (EA) on > > > filesystems that support it (every one of them at this point?). It > > > would take awhile to be adopted by most/all GNOME apps but seems (IMHO) > > > to clearly be the right way to do it. If GNOME VFS supported it then > > > it seems it would be easy to implement for alot of applications. > > > > > > > I agree with you, but while we must provide a quick solution, EA (and > > the attributes themselves) must be standardized cross-unix and > > cross-desktop. This will take some time to mature, since the mechanisms > > for sending files through the Internet (between computers, in general) > > must mature to support EA. I never used Apple operating systems, but it > > looks like they have such a mechanism. Nothing that a tar with EA > > support could not do. > > > > GNOME must provide room today to support state-of-the-art technologies > > in the future, but must at the same time provide solutions to today's > > users using today's technologies. > > > > > File extenstions are just DUMB and EASILY broken. Sniffing is expensive > > > and unreliable. > > > > Indeed, but it's all we have for now. Now = 2.6. > > I thought this could be fun, so hacked gnome-vfs to save the mime type > on a EA named "mime_type". I think this is a great idea - in particular it gives users something they can adjust if the sniffing gets it wrong. If EAs aren't available, perhaps such "sniff overrides" could be stored using the Nautilus metadata system? Though that would make things even slower. > > When trying to find the mime type for the file, gnome-vfs will first > check if this EA exists. If so, use that for the mime type. If not, > determine the mime type as usual and save it. > > It works only for local files. If you don't have permission to change > the file, the EA will not be saved. And you need a file system which > support EA, of course. I tested it with ext3. Might work with others > too. > > This is a hack, just an exercise to see if it could be beneficial. I did > this just for fun. I did not try to follow coding standards, I have no > intention of maintaining this patch. Although I might try to hack > nautilus to allow changing the mime type (as recorded in the EA). > > The following patch is against gnome-vfs-2.4.1 as found in Fedora. I > attach also a modified SPEC file, just in case someone wants to build > it. From bugtraq@gs2.com.br Mon Jan 5 07:27:19 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from zeus.intra.gs2.com.br (unknown [200.165.137.90]) by mail.gnome.org (Postfix) with ESMTP id 3759218667 for ; Mon, 5 Jan 2004 07:27:17 -0500 (EST) Received: from hermes.intra.gs2.com.br (hermes.intra.gs2.com.br [192.168.1.1]) by zeus.intra.gs2.com.br (Postfix) with ESMTP id 245F0302D1; Mon, 5 Jan 2004 09:33:37 -0300 (BRT) Subject: Re: Suggestion for file type detection approach From: Fabio Gomes To: Rodney Dawes Cc: ejk@ucsc.edu, gnome-vfs-list@gnome.org In-Reply-To: <1073238454.26541.173.camel@blackbox.boston.ximian.com> References: <1073083582.3530.77.camel@whipple> <1073238454.26541.173.camel@blackbox.boston.ximian.com> Content-Type: text/plain; charset=UTF-8 Message-Id: <1073305961.1035.25.camel@hermes.intra.gs2.com.br> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 09:32:42 -0300 Content-Transfer-Encoding: 8bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Em Dom, 2004-01-04 às 14:47, Rodney Dawes escreveu: > On Pre , 2004-01-02 at 17:46, Edward Jay Kreps wrote: > > >Given the performance bottleneck imposed by sniffing, I suggest that it > > >is not used anymore in directory listing routines. It should be used > > >when the user tries to open an unknown file. Let's imagine this case: > > > > I don't think this is a good way of thinking about things. The questions are: > > 1. Is sniffing a good idea? > > 2. If so does it work correctly? > > 3. If (1) and (2), is it performing fast enough? > > > > I think others have argued persuasively that sniffing is a good idea > > since unix doesn't generally give file name suffixes to files (even > > though gnome does), and often files have incorrect suffixes. > > > > A number of people have said that there are instances where sniffing is > > not correctly determining the file type. If true, this is an excellent > > argument for fixing those cases, but not at all an argument for throwing > > away sniffing altogether. > > I've only seen one person say that. And as I understand, no real > information was provided. Only a comment of "it broke on this one file." > But yes, it is a good argument for improving the system, not removing > the core functionality. > > > >From your benchmarking it is clear that (3) is a problem, and sniffing > > is taking too long. This is not an argument for getting rid of it > > though, just an argument for speeding it up. Someone suggested running > > it through a profiler, but I doubt that will be worthwhile--the problem > > is almost certainly the multiple disk accesses (your disk is having to > > seek for each file). As others have pointed out, a two pass technique. > > based on extension and then sniffing is also a bad idea since icons, etc > > would change in the case of a discrepancy. > > It is not clear that 3 is a problem. It is only probable that 3 may be > an issue on a certain machine with a certain configuration. I guarantee > that the sniffing is not the bottleneck. Running it through a profiler > will be much more worthwhile than sending mail to a list saying "it's > slow." And yes, I am the one that suggested profiling. The disk i/o is > most certainly not the bottleneck. Given the speed of hard disks today, > seek time is not an issue. Even if it took the 12ms maximum seek time on > a newer model hard disk, and you were loading a directory with 1000 > files in it, that is only 12 seconds. Given the size of cache on newer > hard disks, and the fact that people generally open up the same few > folders, rather than opening / and traversing the tree looking for > things, or opening odd folders randomly, I would guess that the maximum > seek time would be around 3-4 milliseconds. It is much more likely some > other problem that is specific to something Nautilus is doing to display > the list of files. I also suggested other things than profiling, such > as writing specific benchmarks to compare test-mime from gnome-vfs and > file, which would be much more useful than saying "Nautilus must be slow > because echo * is instantaneous" or other such nonsense. Real benchmarks > are much more reliable than "it seemed slow" or "I used a stopwatch", as > human error and perception can misinterpret how long it actually took to > do something. "ONLY" 12 seconds? Is that acceptable for a directory with 1000 files? Can a human error of perception misinterpret the distance between <1s and 20s multiple times with the help of a stopwatch? You must be kidding. :-P > Aye. In general, the speed issues have nothing to do with the way the > mime type is detected. Any claims that one is substantially faster than > the other, is generally due to misperception. The real issues seem to > generally be at a lower level, or totally unrelated, such as the issues > with some of the thumbnailers. Test it by yourself: http://mail.gnome.org/archives/gnome-devel-list/2004-January/msg00010.html If your results confirm my "misperception", I'll blindly agree with everything that you say. :-) I'm not advocating the removal of functionality. People have already pointed how to fix the performance and misidentification issues in efficient manners. What I am trying to do is show the non-believers where the performance problem actually is. Best regards, -- Fabio Gomes de Souza (+55 81 9127-0597) .- GS2 TECNOLOGIA DA INFORMACAO LTDA :: www.gs2.com.br |- IT Infrastructure :: Security :: Embedded systems :: Linux `- Olinda, Brazil - +55 81 3492-7777 - negocios@gs2.com.br From gkarabin@pobox.com Sat Jan 17 20:36:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id B3AD81820C; Sat, 17 Jan 2004 20:36:20 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0I1aHqG013829; Sat, 17 Jan 2004 17:36:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: federico@gnu.org From: George Karabin Subject: tiff multi-document files Date: Sat, 17 Jan 2004 17:36:16 -0800 To: eog-list@gnome.org, gnome-vfs-list@gnome.org X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Scanning and fax applications sometimes store multiple images in a single image/tiff file. I'd like to modify eog to display multi-image tiff files as a flat collection of files, as if it were a directory. Right now it's ignoring the other images in the file. I want to add a gnome-vfs module to map libtiff's directory feature to a gnome-vfs URI with archive-file-format-like methods. For each image file it opens, eog would test to see if it's image/tiff, and then try to open the directory. If the module's installed, then it'll get a directory handle and create the collection. Does the idea sound OK in principle for eog? I'm not sure how much eog wants to know about file-format-specific stuff like this, so I'm asking up-front. I don't think it makes sense to handle these sorts of files in gdk - this doesn't really map well to the animation interface, and there wouldn't be enough developers using it to justify changing APIs. So if this is done, eog has to learn about this tiff idiosyncrasy. Likewise, does this sound OK for gnome-vfs? I think there's less controversy here, but this is a fairly obscure use case. I can't imagine too many apps actually caring to use this, so I hope it's not considered bloat and a bad dependency. - George From jens@triq.net Sun Jan 18 05:19:55 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail4.ewetel.de (mail4-141.ewetel.de [212.6.122.141]) by mail.gnome.org (Postfix) with ESMTP id 4208118212; Sun, 18 Jan 2004 05:19:55 -0500 (EST) Received: from galway.darkride.net (dynadsl-080-228-74-180.ewetel.net [80.228.74.180]) by mail4.ewetel.de (8.12.1/8.12.9) with ESMTP id i0IAJqHB026433; Sun, 18 Jan 2004 11:19:53 +0100 (MET) Date: Sun, 18 Jan 2004 11:34:27 +0100 (CET) From: Jens Finke X-X-Sender: jens@galway.darkride.net To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org Subject: Re: tiff multi-document files In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-CheckCompat: OK Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi George, On Sat, 17 Jan 2004, George Karabin wrote: > I want to add a gnome-vfs module to map libtiff's directory feature to > a gnome-vfs URI with archive-file-format-like methods. For each image > file it opens, eog would test to see if it's image/tiff, and then try > to open the directory. If the module's installed, then it'll get a > directory handle and create the collection. Nice. > Does the idea sound OK in principle for eog? I'm not sure how much eog > wants to know about file-format-specific stuff like this, so I'm asking > up-front. I don't think it makes sense to handle these sorts of files > in gdk - this doesn't really map well to the animation interface, and > there wouldn't be enough developers using it to justify changing APIs. > So if this is done, eog has to learn about this tiff idiosyncrasy. > > Likewise, does this sound OK for gnome-vfs? I think there's less > controversy here, but this is a fairly obscure use case. I can't > imagine too many apps actually caring to use this, so I hope it's not > considered bloat and a bad dependency. Actually, I think it should be possible to write a gnome-vfs module, which adds a new URI scheme and handles such tiff files properly. If it behaves like a directory from the gnome-vfs client point of view, eog will automatically use the collection view for this then. I am not very familar with 3rd party gnome-vfs modules, but AFAICS you neither need to touch gnome-vfs nor eog to get this working. Regards, Jens From alexl@redhat.com Mon Jan 19 04:39:29 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 2721E180EB; Mon, 19 Jan 2004 04:39:29 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNl31117; Mon, 19 Jan 2004 04:39:23 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0J9dNa09346; Mon, 19 Jan 2004 04:39:23 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0J9d1cG019229; Mon, 19 Jan 2004 04:39:02 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: Jens Finke Cc: George Karabin , eog-list@gnome.org, gnome-vfs-list@gnome.org, federico@gnu.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 19 Jan 2004 10:39:21 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > > Does the idea sound OK in principle for eog? I'm not sure how much eog > > wants to know about file-format-specific stuff like this, so I'm asking > > up-front. I don't think it makes sense to handle these sorts of files > > in gdk - this doesn't really map well to the animation interface, and > > there wouldn't be enough developers using it to justify changing APIs. > > So if this is done, eog has to learn about this tiff idiosyncrasy. > > > > Likewise, does this sound OK for gnome-vfs? I think there's less > > controversy here, but this is a fairly obscure use case. I can't > > imagine too many apps actually caring to use this, so I hope it's not > > considered bloat and a bad dependency. > > Actually, I think it should be possible to write a gnome-vfs module, which > adds a new URI scheme and handles such tiff files properly. If it behaves > like a directory from the gnome-vfs client point of view, eog will > automatically use the collection view for this then. This is called "chained uris", and gnome-vfs has some code for it. However, at the moment it just doesn't work. My hope is that eventually we'll get it fixed though. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded vegetarian card sharp with a robot buddy named Sparky. She's a mistrustful paranoid cab driver with her own daytime radio talk show. They fight crime! From gkarabin@pobox.com Mon Jan 19 16:49:06 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from util.ext.ti.com (util.ext.ti.com [192.91.75.135]) by mail.gnome.org (Postfix) with ESMTP id 15A5D180FE for ; Mon, 19 Jan 2004 16:49:06 -0500 (EST) Received: from dlep51.itg.ti.com ([157.170.141.75]) by util.ext.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn55O004430 for ; Mon, 19 Jan 2004 15:49:05 -0600 (CST) Received: from sdca.asp.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.10/8.12.10) with ESMTP id i0JLn4rj024363 for ; Mon, 19 Jan 2004 15:49:04 -0600 (CST) Received: from [146.252.133.9] (HELO pobox.com) by sdca.asp.ti.com (CommuniGate Pro SMTP 4.0.5) with ESMTP id 3657067 for gnome-vfs-list@gnome.org; Mon, 19 Jan 2004 13:59:43 -0800 Message-ID: <400C50D0.3090701@pobox.com> Date: Mon, 19 Jan 2004 13:49:04 -0800 From: George J Karabin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gnome-vfs-list@gnome.org Subject: [patch] tar method won't open root directory of archive Content-Type: multipart/mixed; boundary="------------060702050303070000000102" Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------060702050303070000000102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I haven't seen any documentation in gnome-vfs to indicate how one should encode the root directory of an archive into a URI, but empirically, it looks like something like either "foo.tar#tar:" or "foo.tar#tar:/" should work (gnome-vfs expands the former to the latter before giving the uri to the module's method). The tar method doesn't handle either of these cases. The attached patch fixes this. Try out something like "gnomevfs-ls /path-to-file/foo.tar#:" before and after the patch as a test case. No CVS access for me - can someone apply it if it passes review? The problem's filed in bugzilla as well: http://bugzilla.gnome.org/show_bug.cgi?id=131959 - George --------------060702050303070000000102 Content-Type: text/plain; name="gnome-vfs-2.4.1-handle-root.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gnome-vfs-2.4.1-handle-root.patch" --- gnome-vfs-2.4.1/modules/tar-method.c.handle-root 2002-05-12 20:38:29.000000000 -0700 +++ gnome-vfs-2.4.1/modules/tar-method.c 2004-01-19 12:43:14.000000000 -0800 @@ -51,6 +51,7 @@ int current_index; gchar *filename; gboolean is_directory; + gboolean is_root; } FileHandle; #define TARPET_BLOCKSIZE (sizeof (union TARPET_block)) @@ -154,35 +155,42 @@ return ret; } -static GNode* -tree_lookup_entry (const GNode *tree, const gchar *name) +static gboolean +tree_lookup_entry (const GNode *tree, const gchar *name, GNode **node) { - GNode *ret; char *root = g_strdup (name); char *txt = root; - - if (txt[0] == '/') - txt++; - ret = real_lookup_entry (tree, txt, 1); - if (!ret && txt[strlen (txt) - 1] != '/') + if (txt[0] == '/') + { + if (txt[1] == '\0') + { + g_free (root); + return TRUE; + } + else + txt++; + } + + *node = real_lookup_entry (tree, txt, 1); + if (!*node && txt[strlen (txt) - 1] != '/') { txt = g_strconcat (txt, "/", NULL); g_free (root); root = txt; - ret = real_lookup_entry (tree, txt, 1); + *node = real_lookup_entry (tree, txt, 1); } g_free (root); - if (ret && ret != tree->children) + if (*node && *node != tree->children) { - union TARPET_block *b = ret->data; + union TARPET_block *b = (*node)->data; b--; if (b->p.typeflag == TARPET_TYPE_LONGFILEN) - ret = ret->next; + *node = (*node)->next; } - return ret; + return FALSE; } static TarFile* read_tar_file (GnomeVFSHandle *handle) @@ -228,7 +236,7 @@ } split_name (ret->blocks[i].p.name, &dir, &rest); - node = tree_lookup_entry (ret->info_tree, dir); + tree_lookup_entry (ret->info_tree, dir, &node); if (!node) { @@ -322,7 +330,7 @@ tar = ensure_tarfile (uri); if (!tar) return GNOME_VFS_ERROR_BAD_FILE; - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); if (!node) { tar_file_unref (tar); @@ -468,13 +476,17 @@ union TARPET_block *start, *current; GNode *node; int i; + gboolean is_root; if (!uri->parent) return GNOME_VFS_ERROR_INVALID_URI; tar = ensure_tarfile (uri); if (uri->text) { - node = tree_lookup_entry (tar->info_tree, uri->text); + is_root = tree_lookup_entry (tar->info_tree, uri->text, &node); + } + if (!is_root) + { if (!node) { tar_file_unref (tar); @@ -490,8 +502,11 @@ else current = NULL; } - else + if (is_root || !uri->text) { + /* FIXME: gnome-vfs never seems to generate !uri->text + condition. Is it permissible by contract? */ + node = tar->info_tree; if (!node) { @@ -516,6 +531,7 @@ break; new_handle->current_index = i; new_handle->is_directory = TRUE; + new_handle->is_root = is_root; *method_handle = (GnomeVFSMethodHandle*) new_handle; @@ -550,7 +566,7 @@ int i; if (uri->text) - node = tree_lookup_entry (tar->info_tree, uri->text); + tree_lookup_entry (tar->info_tree, uri->text, &node); else node = tar->info_tree->children; @@ -635,15 +651,16 @@ GnomeVFSURI *uri; gchar *str; GNode *node; - + gboolean is_root; + if (!handle->current) return GNOME_VFS_ERROR_EOF; str = g_strconcat (handle->filename, "#tar:", handle->current->p.name, NULL); uri = gnome_vfs_uri_new (str); do_get_file_info (method, uri, file_info, 0, context); - node = tree_lookup_entry (handle->tar->info_tree, uri->text); - if (!node) + is_root = tree_lookup_entry (handle->tar->info_tree, uri->text, &node); + if (!node && !is_root) { gnome_vfs_uri_unref (uri); return GNOME_VFS_ERROR_NOT_FOUND; --------------060702050303070000000102-- From cbhoh@yahoo.com Tue Jan 20 01:36:27 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60307.mail.yahoo.com (web60307.mail.yahoo.com [216.109.118.118]) by mail.gnome.org (Postfix) with SMTP id 58F7518675 for ; Tue, 20 Jan 2004 01:36:27 -0500 (EST) Message-ID: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Received: from [161.142.100.80] by web60307.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 22:36:27 PST Date: Mon, 19 Jan 2004 22:36:27 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: gnome_vfs_get_mime_type does NOT get the mime_type To: gnome-vfs-list@gnome.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hi guys, I need some help here, today I just use jhbuild to rebuild the 2.5 gnome. I noticed that the gnome_vfs_get_mime_type or gnome_vfs_get_mime_type_from_uri does not work. since the latest yelp use the gnome-vfs to determine the correct mimetype and then respond to the help file according to mime-type. For whatever file I use gnome_vfs_get_mime_type to retrive, I keep getting application/octect-stream. Is there anything i miss out about ? HOH ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Tue Jan 20 02:17:30 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133]) by mail.gnome.org (Postfix) with ESMTP id 9E92818136; Tue, 20 Jan 2004 02:17:29 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-01-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0K7HPqG014225; Mon, 19 Jan 2004 23:17:25 -0800 (PST) In-Reply-To: <1074505161.2413.109.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Mon, 19 Jan 2004 23:17:26 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: >> Actually, I think it should be possible to write a gnome-vfs module, >> which >> adds a new URI scheme and handles such tiff files properly. If it >> behaves >> like a directory from the gnome-vfs client point of view, eog will >> automatically use the collection view for this then. > > This is called "chained uris", and gnome-vfs has some code for it. > However, at the moment it just doesn't work. My hope is that eventually > we'll get it fixed though. I looked at the archives for this list on chaining and the shared vfs ideas on xdg-list. Has anything come of your idea for a common VFS URI spec: https://listman.redhat.com/archives/xdg-list/2003-September/ msg00110.html ? Do you think it makes any sense to attempt to fix chaining before attempting such a spec? Regarding a VFS URI spec, I thought I'd go looking for relevant internet standards and drafts, and note them here. They might make for some good references for requirements gathering for anyone thinking about such a spec. Anyway, RFC 2396 provides a general BNF for URIs that seems workable[1]. RFC 2396bis was in the running to succeed it, but expired in December. It had expanded on encoding and escaping guidelines, which 2396 was really vague on, but basically left the specifics for URI components to TBD docs that describe those URIs. I.e., no conclusive help here anytime soon. I don't know why it lost momentum, and am not sure if there's any sense trying to salvage some of its ideas or not. Maybe it makes sense to get URIs that VFS projects care about into ietf drafts? Looks to be a slow-moving standards body - dunno if it's worth the effort or not - I don't have any experience with standards bodies. RFC 1738 provides rules for some specific URI types. RFC1738bis is an update based on 2396bis, so it's left hanging as well. The ssh URI draft that Jeff Waugh referred to some time back is based on other drafts that are based on the expired 2396bis, so it seems likely that it'll expire as well unless 239bis picks up again. Interesting RFCs: ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt ftp://ftp.rfc-editor.org/in-notes/rfc1738.txt ftp://ftp.rfc-editor.org/in-notes/rfc2079.txt ftp://ftp.rfc-editor.org/in-notes/rfc2483.txt ftp://ftp.rfc-editor.org/in-notes/rfc2168.txt Other relevant/interesting drafts: http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri- rfc2396bis-03.txt (expired) http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-06.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri -01.txt - George [1] It's old enough that for all I know gnome-vfs or kio could be based on it. I have no idea if that's the case or not. From alexl@redhat.com Tue Jan 20 03:00:52 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9DB8618958; Tue, 20 Jan 2004 03:00:52 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80ql14111; Tue, 20 Jan 2004 03:00:52 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0K80qa30628; Tue, 20 Jan 2004 03:00:52 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0K80UcG000940; Tue, 20 Jan 2004 03:00:31 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040120063627.8391.qmail@web60307.mail.yahoo.com> References: <20040120063627.8391.qmail@web60307.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074585650.2413.185.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 20 Jan 2004 09:00:51 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 07:36, Chee Bin HOH wrote: > Hi guys, > > I need some help here, today I just use jhbuild to > rebuild the 2.5 gnome. I noticed that the > gnome_vfs_get_mime_type or > gnome_vfs_get_mime_type_from_uri does not work. > > since the latest yelp use the gnome-vfs to determine > the correct mimetype and then respond to the help file > according to mime-type. > > For whatever file I use gnome_vfs_get_mime_type to > retrive, I keep getting application/octect-stream. > > Is there anything i miss out about ? Did you install shared-mime-info? Did you set XDG_DATA_DIRS to include $prefix/share? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a globe-trotting skateboarding hairdresser who dotes on his loving old ma. She's a foxy cat-loving barmaid with an incredible destiny. They fight crime! From cbhoh@yahoo.com Wed Jan 21 01:47:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60309.mail.yahoo.com (web60309.mail.yahoo.com [216.109.118.120]) by mail.gnome.org (Postfix) with SMTP id 59D2718254 for ; Wed, 21 Jan 2004 01:47:13 -0500 (EST) Message-ID: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Received: from [161.142.195.153] by web60309.mail.yahoo.com via HTTP; Tue, 20 Jan 2004 21:20:17 PST Date: Tue, 20 Jan 2004 21:20:17 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074585650.2413.185.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --- Alexander Larsson wrote: > Did you install shared-mime-info? Did you set > XDG_DATA_DIRS to include > $prefix/share? I did install share-mime-info from cvs.freedesktop.org (as requested by jhbuild), but I did not set the env XDG_DATA_DIRS. I need to set XDG_DATA_DIRS while I build share-mime-info or others? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a globe-trotting skateboarding hairdresser who > dotes on his loving old > ma. She's a foxy cat-loving barmaid with an > incredible destiny. They fight > crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From alexl@redhat.com Wed Jan 21 05:27:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 9AF4B181E9; Wed, 21 Jan 2004 05:27:50 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARol29294; Wed, 21 Jan 2004 05:27:50 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARoa13682; Wed, 21 Jan 2004 05:27:50 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LARScG018691; Wed, 21 Jan 2004 05:27:28 -0500 Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type From: Alexander Larsson To: cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <20040121052017.24059.qmail@web60309.mail.yahoo.com> References: <20040121052017.24059.qmail@web60309.mail.yahoo.com> Content-Type: text/plain Message-Id: <1074680868.2413.359.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:49 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > --- Alexander Larsson wrote: > > Did you install shared-mime-info? Did you set > > XDG_DATA_DIRS to include > > $prefix/share? > > I did install share-mime-info from cvs.freedesktop.org > (as requested by jhbuild), but I did not set the env > XDG_DATA_DIRS. > > I need to set XDG_DATA_DIRS while I build > share-mime-info or others? No, not while building. You need to set it when running apps. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a genetically engineered vegetarian inventor with a winning smile and a way with the ladies. She's a beautiful nymphomaniac research scientist on the trail of a serial killer. They fight crime! From alexl@redhat.com Wed Jan 21 05:27:13 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 37B74181E9; Wed, 21 Jan 2004 05:27:13 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBl29170; Wed, 21 Jan 2004 05:27:11 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0LARBa13574; Wed, 21 Jan 2004 05:27:11 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0LAQmcG018568; Wed, 21 Jan 2004 05:26:49 -0500 Subject: Re: tiff multi-document files From: Alexander Larsson To: George Karabin Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org In-Reply-To: References: <1074505161.2413.109.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 21 Jan 2004 11:27:09 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Tue, 2004-01-20 at 08:17, George Karabin wrote: > On Jan 19, 2004, at 1:39 AM, Alexander Larsson wrote: > > > On Sun, 2004-01-18 at 11:34, Jens Finke wrote: > >> Actually, I think it should be possible to write a gnome-vfs module, > >> which > >> adds a new URI scheme and handles such tiff files properly. If it > >> behaves > >> like a directory from the gnome-vfs client point of view, eog will > >> automatically use the collection view for this then. > > > > This is called "chained uris", and gnome-vfs has some code for it. > > However, at the moment it just doesn't work. My hope is that eventually > > we'll get it fixed though. > > > I looked at the archives for this list on chaining and the shared vfs > ideas on xdg-list. Has anything come of your idea for a common VFS URI > spec: > https://listman.redhat.com/archives/xdg-list/2003-September/ > msg00110.html ? Do you think it makes any sense to attempt to fix > chaining before attempting such a spec? There hasn't been any work on it that I know of. And in such a spec it would be nice if chaining was supported. > Regarding a VFS URI spec, I thought I'd go looking for relevant > internet standards and drafts, and note them here. They might make for > some good references for requirements gathering for anyone thinking > about such a spec. In some sense its sort of unfortunate that gnome-vfs uris are based on normal URIs, because that limits us a bit and in some cases it causes trouble because people expect that gnome-vfs should support all sorts of things you can do with web-uris, such as mailto:, callto:, javascript: etc. In fact, we partially handle these by installing handler app settings for them, but in reality they are not really gnome-vfs uris. The way gnome-vfs currently handles chained uris is described in gnome-vfs/doc/uri.txt. Its working to some extent, but the work has never really been finalized and polished up to work in the desktop. To make it work you'd have to: * Work on the chained methods (zip, tar, gzip etc) to make them work better than they do today. The existance of the gnome-vfs daemon in 2.5 should make this easier * Finish the work with putting chained uri handlers into the mime info, so that the file manager can now what file types are chainable * Make the file handler recognize chainable file types and browse them * Make all users of gnome-vfs correctly handle chained uris (i.e. gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns file:///some/file.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an old-fashioned day-dreaming Green Beret possessed of the uncanny powers of an insect. She's a cold-hearted antique-collecting hooker married to the Mob. They fight crime! From cbhoh@yahoo.com Wed Jan 21 06:22:51 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from web60306.mail.yahoo.com (web60306.mail.yahoo.com [216.109.118.117]) by mail.gnome.org (Postfix) with SMTP id 9AC8718422 for ; Wed, 21 Jan 2004 06:22:51 -0500 (EST) Message-ID: <20040121112245.44069.qmail@web60306.mail.yahoo.com> Received: from [161.142.195.41] by web60306.mail.yahoo.com via HTTP; Wed, 21 Jan 2004 03:22:45 PST Date: Wed, 21 Jan 2004 03:22:45 -0800 (PST) From: Chee Bin HOH Reply-To: cbhoh@gnome.org Subject: Re: gnome_vfs_get_mime_type does NOT get the mime_type To: Alexander Larsson , cbhoh@gnome.org Cc: gnome-vfs-list@gnome.org In-Reply-To: <1074680868.2413.359.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: Hey, it works. ;) Thank! --- Alexander Larsson wrote: > On Wed, 2004-01-21 at 06:20, Chee Bin HOH wrote: > > --- Alexander Larsson wrote: > > > Did you install shared-mime-info? Did you set > > > XDG_DATA_DIRS to include > > > $prefix/share? > > > > I did install share-mime-info from > cvs.freedesktop.org > > (as requested by jhbuild), but I did not set the > env > > XDG_DATA_DIRS. > > > > I need to set XDG_DATA_DIRS while I build > > share-mime-info or others? > > No, not while building. You need to set it when > running apps. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson > Red Hat, Inc > alexl@redhat.com > alla@lysator.liu.se > He's a genetically engineered vegetarian inventor > with a winning smile and a > way with the ladies. She's a beautiful nymphomaniac > research scientist on the > trail of a serial killer. They fight crime! > ===== Chee Bin HOH Where we're going, we don't need roads..., http://www.gnome.org Free Software - `Free` as in Freedom, http://www.gnu.org/philosophy/philosophy.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From gkarabin@pobox.com Sat Jan 24 00:53:14 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from ms-smtp-03-eri0.socal.rr.com (ms-smtp-03-qfe0.socal.rr.com [66.75.162.135]) by mail.gnome.org (Postfix) with ESMTP id 73D0A182A2; Sat, 24 Jan 2004 00:53:14 -0500 (EST) Received: from [192.168.1.100] (dt033n72.san.rr.com [24.30.138.114]) by ms-smtp-03-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i0O5rAF3022083; Fri, 23 Jan 2004 21:53:11 -0800 (PST) In-Reply-To: <1074680829.2413.357.camel@localhost.localdomain> References: <1074505161.2413.109.camel@localhost.localdomain> <1074680829.2413.357.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9618B740-4E31-11D8-B6FD-000A95A6935E@pobox.com> Content-Transfer-Encoding: 7bit Cc: eog-list@gnome.org, gnome-vfs-list@gnome.org, Jens Finke , federico@gnu.org From: George Karabin Subject: Re: tiff multi-document files Date: Fri, 23 Jan 2004 21:53:08 -0800 To: Alexander Larsson X-Mailer: Apple Mail (2.609) X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Jan 21, 2004, at 2:27 AM, Alexander Larsson wrote: > In some sense its sort of unfortunate that gnome-vfs uris are based on > normal URIs, because that limits us a bit and in some cases it causes > trouble because people expect that gnome-vfs should support all sorts > of > things you can do with web-uris, such as mailto:, callto:, javascript: > etc. In fact, we partially handle these by installing handler app > settings for them, but in reality they are not really gnome-vfs uris. Regarding the IETF docs, the thing I'm most interested in is to be sure that the grammar that they publish for URIs are the same as what gnome-vfs uses, so that URIs that are appropriate to the VFS can be generated from some external source, and be handled by a gnome-vfs client that doesn't necessarily know it's content. > The way gnome-vfs currently handles chained uris is described in > gnome-vfs/doc/uri.txt. Its working to some extent, but the work has > never really been finalized and polished up to work in the desktop. > Thanks - the text files aren't in the release tarballs. Looking at them in cvs helps out a lot. > To make it work you'd have to: > * Work on the chained methods (zip, tar, gzip etc) to make them work > better than they do today. The existance of the gnome-vfs daemon in 2.5 > should make this easier > * Finish the work with putting chained uri handlers into the mime info, > so that the file manager can now what file types are chainable > * Make the file handler recognize chainable file types and browse them > * Make all users of gnome-vfs correctly handle chained uris (i.e. > gnome_vfs_uri_get_parent() on file:///some/file#foo:/ returns > file:///some/file.) Thanks for the laundry list - I can start working toward these. I'll be away from email for a few days, but I'll be working my way through the new code over the course of the week. - George From thomas.cataldo@aliacom.fr Sun Jan 25 09:14:21 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0902.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 36753187E9 for ; Sun, 25 Jan 2004 09:14:21 -0500 (EST) Received: from localhost (AToulouse-206-1-16-219.w81-50.abo.wanadoo.fr [81.50.219.219]) by mwinf0902.wanadoo.fr (SMTP Server) with ESMTP id 8F0FD18000CC for ; Sun, 25 Jan 2004 15:14:19 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 0A33410712E for ; Sun, 25 Jan 2004 15:09:12 +0100 (CET) Subject: [PATCH] nntp method leak fixes From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-P0V5Zy6gc1b7U4iju1UH" Message-Id: <1075039751.12033.9.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 25 Jan 2004 15:09:12 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-P0V5Zy6gc1b7U4iju1UH Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, Here is a patch to fix a few leaks in the nntp method. I tested it using gnomevfs-ls nntp:///alt.binaries.anime regards, Thomas. --=-P0V5Zy6gc1b7U4iju1UH Content-Disposition: attachment; filename=nntp-method-leaks.diff Content-Type: text/x-patch; name=nntp-method-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1715 diff -u -r1.1715 ChangeLog --- ChangeLog 23 Jan 2004 09:59:44 -0000 1.1715 +++ ChangeLog 25 Jan 2004 13:58:56 -0000 @@ -1,3 +1,8 @@ +2004-01-25 Thomas Cataldo + + * modules/nntp-method.c: (parse_date_string), (parse_header): some + memory leak fixes. + 2004-01-23 Alexander Larsson * schemas/Makefile.am: Index: modules/nntp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/nntp-method.c,v retrieving revision 1.5 diff -u -r1.5 nntp-method.c --- modules/nntp-method.c 16 Jun 2002 23:43:35 -0000 1.5 +++ modules/nntp-method.c 25 Jan 2004 13:58:57 -0000 @@ -814,6 +814,12 @@ g_message("error parsing %s, %s", date_string, temp_str); } + if (filename != NULL) { + g_free (filename); + } + if (linkname != NULL) { + g_free (linkname); + } g_free(temp_str); *t = s.st_mtime; @@ -904,6 +910,8 @@ file_start = strrchr (temp_str, '-'); if (file_start == NULL) { + g_free (*message_id); + g_free (temp_str); return FALSE; } --=-P0V5Zy6gc1b7U4iju1UH-- From cbhoh@mimos.my Wed Jan 28 05:45:42 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 28 Jan 2004 18:39:13 +0800 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH From thomas.cataldo@aliacom.fr Thu Jan 29 21:06:53 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0904.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id 32FD318B2C for ; Thu, 29 Jan 2004 21:06:53 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0904.wanadoo.fr (SMTP Server) with ESMTP id 951C0180012A for ; Fri, 30 Jan 2004 03:06:49 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id 82288106FD4 for ; Fri, 30 Jan 2004 03:00:53 +0100 (CET) Subject: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: gnome-vfs-list@gnome.org Content-Type: multipart/mixed; boundary="=-vEputk1gGiSFtfo2JnkO" Message-Id: <1075428053.15247.11.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 03:00:53 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: --=-vEputk1gGiSFtfo2JnkO Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests agains ftp and http urls. By the way, as my previous patch against the nntp method was not reviewed, could you tell me if this list is the right place to send patches, or if a bug report is a better way. cheers, Thomas. --=-vEputk1gGiSFtfo2JnkO Content-Disposition: attachment; filename=vfs-socket-leaks.diff Content-Type: text/x-patch; name=vfs-socket-leaks.diff; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Index: ChangeLog =================================================================== RCS file: /cvs/gnome/gnome-vfs/ChangeLog,v retrieving revision 1.1716 diff -u -r1.1716 ChangeLog --- ChangeLog 27 Jan 2004 18:59:08 -0000 1.1716 +++ ChangeLog 30 Jan 2004 01:55:40 -0000 @@ -1,3 +1,12 @@ +2004-01-30 Thomas Cataldo + + plug some gnome_vfs_socket leaks. + + * libgnomevfs/gnome-vfs-socket-buffer.c: + (gnome_vfs_socket_buffer_destroy): + * modules/ftp-method.c: (do_transfer_command), (end_transfer), + (ftp_connection_create), (ftp_connection_destroy): + 2004-01-27 David Hawthorne * daemon/gnome-vfs-daemon.c Index: libgnomevfs/gnome-vfs-socket-buffer.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/libgnomevfs/gnome-vfs-socket-buffer.c,v retrieving revision 1.8 diff -u -r1.8 gnome-vfs-socket-buffer.c --- libgnomevfs/gnome-vfs-socket-buffer.c 15 Jan 2004 09:55:51 -0000 1.8 +++ libgnomevfs/gnome-vfs-socket-buffer.c 30 Jan 2004 01:55:41 -0000 @@ -104,6 +104,7 @@ if (close_socket) { gnome_vfs_socket_close (socket_buffer->socket); + g_free(socket_buffer->socket); } g_free (socket_buffer); return GNOME_VFS_OK; Index: modules/ftp-method.c =================================================================== RCS file: /cvs/gnome/gnome-vfs/modules/ftp-method.c,v retrieving revision 1.96 diff -u -r1.96 ftp-method.c --- modules/ftp-method.c 22 Jan 2004 12:29:10 -0000 1.96 +++ modules/ftp-method.c 30 Jan 2004 01:55:44 -0000 @@ -62,14 +62,12 @@ typedef struct { GnomeVFSMethodHandle method_handle; - GnomeVFSInetConnection *inet_connection; GnomeVFSSocketBuffer *socket_buf; GnomeVFSURI *uri; gchar *cwd; GString *response_buffer; gchar *response_message; gint response_code; - GnomeVFSInetConnection *data_connection; GnomeVFSSocketBuffer *data_socketbuf; GnomeVFSFileOffset offset; enum { @@ -384,6 +382,7 @@ char *host = NULL; gint port; GnomeVFSResult result; + GnomeVFSInetConnection *data_connection; GnomeVFSSocket *socket; /* Image mode (binary to the uninitiated) */ @@ -414,7 +413,7 @@ } /* connect */ - result = gnome_vfs_inet_connection_create (&conn->data_connection, + result = gnome_vfs_inet_connection_create (&data_connection, host, port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -424,16 +423,10 @@ return result; } - socket = gnome_vfs_inet_connection_to_socket (conn->data_connection); + socket = gnome_vfs_inet_connection_to_socket (data_connection); conn->data_socketbuf = gnome_vfs_socket_buffer_new (socket); - if (conn->socket_buf == NULL) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - return GNOME_VFS_ERROR_GENERIC; - } - - if (conn->offset) - { + if (conn->offset) { gchar *tmpstring; tmpstring = g_strdup_printf ("REST %Lu", conn->offset); @@ -441,8 +434,7 @@ g_free (tmpstring); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } } @@ -450,16 +442,14 @@ result = do_control_write (conn, command); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } result = get_response (conn); if (result != GNOME_VFS_OK) { - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); return result; } @@ -501,15 +491,10 @@ if(conn->data_socketbuf) { gnome_vfs_socket_buffer_flush (conn->data_socketbuf); - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); conn->data_socketbuf = NULL; } - if (conn->data_connection) { - gnome_vfs_inet_connection_destroy (conn->data_connection, NULL); - conn->data_connection = NULL; - } - result = get_response (conn); return result; @@ -545,6 +530,7 @@ gint port = control_port; const gchar *user = anon_user; const gchar *pass = anon_pass; + GnomeVFSInetConnection* inet_connection; conn->uri = gnome_vfs_uri_dup (uri); conn->response_buffer = g_string_new (""); @@ -565,7 +551,7 @@ pass = gnome_vfs_uri_get_password (uri); } - result = gnome_vfs_inet_connection_create (&conn->inet_connection, + result = gnome_vfs_inet_connection_create (&inet_connection, gnome_vfs_uri_get_host_name (uri), port, context ? gnome_vfs_context_get_cancellation(context) : NULL); @@ -581,11 +567,11 @@ return result; } - conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (conn->inet_connection); + conn->socket_buf = gnome_vfs_inet_connection_to_socket_buffer (inet_connection); if (conn->socket_buf == NULL) { g_warning ("Getting socket buffer failed"); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_inet_connection_destroy (inet_connection, NULL); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -612,8 +598,7 @@ /* login failed */ g_warning ("FTP server said: \"%d %s\"\n", conn->response_code, conn->response_message); - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_string_free (conn->response_buffer, TRUE); g_free (conn); @@ -645,11 +630,8 @@ ftp_connection_destroy (FtpConnection *conn) { - if (conn->inet_connection) - gnome_vfs_inet_connection_destroy (conn->inet_connection, NULL); - if (conn->socket_buf) - gnome_vfs_socket_buffer_destroy (conn->socket_buf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->socket_buf, TRUE); gnome_vfs_uri_unref (conn->uri); g_free (conn->cwd); @@ -659,11 +641,8 @@ g_free (conn->response_message); g_free (conn->server_type); - if (conn->data_connection) - gnome_vfs_inet_connection_destroy(conn->data_connection, NULL); - if (conn->data_socketbuf) - gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, FALSE); + gnome_vfs_socket_buffer_destroy (conn->data_socketbuf, TRUE); g_free (conn->dirlist); g_free (conn->dirlistptr); --=-vEputk1gGiSFtfo2JnkO-- From alexl@redhat.com Fri Jan 30 03:05:39 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by mail.gnome.org (Postfix) with ESMTP id 42D57182E3 for ; Fri, 30 Jan 2004 03:05:39 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Vb24660; Fri, 30 Jan 2004 03:05:31 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0U85Ua05769; Fri, 30 Jan 2004 03:05:30 -0500 Received: from localhost (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i0U853kC017335; Fri, 30 Jan 2004 03:05:04 -0500 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Alexander Larsson To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Message-Id: <1075449929.8585.37.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (Preview Release) Date: 30 Jan 2004 09:05:29 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > Hi, > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > agains ftp and http urls. > > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. Nah, it works. Christophe or I will get to it eventually. I'm just horribly busy with other stuff at the moment. Your first patch is tagged in my inbox and will get attention when i have time. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's a jaded coffee-fuelled cop from a doomed world. She's a strong-willed thirtysomething Valkyrie descended from a line of powerful witches. They fight crime! From thomas.cataldo@aliacom.fr Fri Jan 30 03:13:22 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mwinf0901.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by mail.gnome.org (Postfix) with ESMTP id C0FDC18FF9 for ; Fri, 30 Jan 2004 03:13:10 -0500 (EST) Received: from localhost (AToulouse-206-1-7-2.w81-50.abo.wanadoo.fr [81.50.197.2]) by mwinf0901.wanadoo.fr (SMTP Server) with ESMTP id 8EA02180021B; Fri, 30 Jan 2004 09:13:02 +0100 (CET) Received: from buffy.cataldo.local (buffy [192.168.0.254]) by localhost (Postfix) with ESMTP id D1619106FD4; Fri, 30 Jan 2004 09:07:03 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Alexander Larsson Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075449929.8585.37.camel@localhost.localdomain> References: <1075428053.15247.11.camel@buffy> <1075449929.8585.37.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1075450023.15247.13.camel@buffy> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 09:07:03 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 09:05, Alexander Larsson wrote: > On Fri, 2004-01-30 at 03:00, Thomas Cataldo wrote: > > Hi, > > > > The attached patch was made after some valgrind/gnomevfs-(cat|ls) tests > > agains ftp and http urls. > > > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > Nah, it works. Christophe or I will get to it eventually. I'm just > horribly busy with other stuff at the moment. Your first patch is tagged > in my inbox and will get attention when i have time. Ok, thanks for the quick reply. From root@cavtel.net Thu Jan 29 17:38:23 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from xx.mx.cavtel.net (xx.mx.cavtel.net [64.83.1.45]) by mail.gnome.org (Postfix) with ESMTP id 5A15618E5F; Thu, 29 Jan 2004 17:38:23 -0500 (EST) Received: by xx.mx.cavtel.net (Postfix, from userid 0) id CEE681D42C8; Thu, 29 Jan 2004 17:38:22 -0500 (EST) Received: from msg2.cavtel.net (msg2.mx.cavtel.net [64.83.1.144]) by xx.mx.cavtel.net (Postfix) with ESMTP id 96E8A4382D for ; Wed, 28 Jan 2004 06:17:55 -0500 (EST) Received: by msg2.cavtel.net (Postfix, from userid 1002) id B49283139E; Wed, 28 Jan 2004 06:02:41 -0500 (EST) Received: from mail.gnome.org (moniker.gnome.org [67.72.78.218]) by msg2.cavtel.net (Postfix) with ESMTP id 3E3E431B89 for ; Wed, 28 Jan 2004 05:58:12 -0500 (EST) Received: from moniker.gnome.org (moniker.gnome.org [127.0.0.1]) by mail.gnome.org (Postfix) with ESMTP id A8B08184D1; Wed, 28 Jan 2004 05:59:25 -0500 (EST) Delivered-To: desktop-devel-list@gnome.org Received: from filter.mimos.my (filter.mimos.my [192.228.137.70]) by mail.gnome.org (Postfix) with ESMTP id 416BF183CE; Wed, 28 Jan 2004 05:45:41 -0500 (EST) Received: from ew.mimos.my (localhost.localdomain [127.0.0.1]) by filter.mimos.my (8.11.6/8.11.6) with ESMTP id i0SAjcE16778; Wed, 28 Jan 2004 18:45:38 +0800 Received: (from root@localhost) by ew.mimos.my (8.12.8p2/8.12.3) id i0SAjcsI063008; Wed, 28 Jan 2004 18:45:38 +0800 (MYT) (envelope-from cbhoh@mimos.my) Received: from ivest48.nat.mimos.my (ivest48.nat.mimos.my [10.1.14.48]) by ew.mimos.my (8.12.8p2/8.11.6) with ESMTP id i0SAjboh062279; Wed, 28 Jan 2004 18:45:37 +0800 (MYT) (envelope-from cbhoh@mimos.my) Subject: Where to set XDG_DATA_DIRS upon login? From: Chee Bin HOH Reply-To: cbhoh@mimos.my To: gnome-vfs-list@gnome.org, desktop-devel-list@gnome.org X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/) Content-Type: text/plain Organization: MIMOS Berhad Message-Id: <1075286353.5665.2184.camel@ivest48.nat.mimos.my> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Content-Transfer-Encoding: 7bit X-BeenThere: desktop-devel-list@gnome.org X-Loop: desktop-devel-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk Date: 28 Jan 2004 18:39:13 +0800 X-Bayesian-Class: No, tests=bogofilter, spamicity=0.188133, version=0.15.8 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: I need to set XDG_DATA_DIRS to /share in order to run yelp to view an online help, since the yelp is now using gnome-vfs for identifying the location of the help file. But it fails when I try to view any applet help by clicking on the help item from any applet popup menu. The yelp prompts the error that "There is no default action associated with this location.". I set the environment variable XDG_DATA_DIRS in /etc/gdm/Xsession scripts, and my login session inherits it, but it still does not help me to solve the problem (the yelp invoked by applet through gnome_help_display function still fails). I am able to view the online help of any applet by adding 'setenv ("XDG_DATA_DIRS", "/share") inside the code just before the calling egg_help_display_on_screen or gnome_help_display. I can also view the applet help by calling yelp from a command line (my shell inherit the XDG_DATA_DIRS from /etc/gdm/Xsession), then browse through it. but I just can not click on the help item from applet popup menu. Where should I set the env XDG_DATA_DIRS in order for the whole desktop to function correctly? - HOH _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list From cfergeau@mipsys.com Fri Jan 30 04:11:12 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from bugsbunny.mipsys.com (griffon.mipsys.com [217.167.51.129]) by mail.gnome.org (Postfix) with ESMTP id 1651918A96 for ; Fri, 30 Jan 2004 04:11:12 -0500 (EST) Received: from teuf by bugsbunny.mipsys.com with local (Exim 3.36 #1 (Debian)) id 1AmUfU-0003Nj-00; Fri, 30 Jan 2004 10:10:28 +0100 Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Christophe Fergeau To: Thomas Cataldo Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075428053.15247.11.camel@buffy> References: <1075428053.15247.11.camel@buffy> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1075453828.3843.0.camel@bugsbunny.mipsys.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.3 Date: Fri, 30 Jan 2004 10:10:28 +0100 Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: > By the way, as my previous patch against the nntp method was not > reviewed, could you tell me if this list is the right place to send > patches, or if a bug report is a better way. I prefer having a bug report in addition to mails since I regularly check the pending bugs in bugzilla, and process them as I find time. Christophe From thomas.cataldo@aliacom.fr Fri Jan 30 04:37:20 2004 Return-Path: Delivered-To: gnome-vfs-list@gnome.org Received: from mail.aliacom.fr (mail.aliacom.fr [213.41.82.82]) by mail.gnome.org (Postfix) with ESMTP id BCDC318FF1; Fri, 30 Jan 2004 04:37:19 -0500 (EST) Received: from chienne.aliacom-local (chienne.aliacom-local [192.168.1.38]) by mail.aliacom.fr (Postfix) with ESMTP id D2AE7202DC; Fri, 30 Jan 2004 10:37:17 +0100 (CET) Subject: Re: [PATCH] plugs GnomeVFSSocket leaks in ftp/http method From: Thomas Cataldo To: Christophe Fergeau Cc: gnome-vfs-list@gnome.org In-Reply-To: <1075453828.3843.0.camel@bugsbunny.mipsys.com> References: <1075428053.15247.11.camel@buffy> <1075453828.3843.0.camel@bugsbunny.mipsys.com> Content-Type: text/plain Organization: Aliacom Message-Id: <1075455508.14823.17.camel@chienne.aliacom-local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Jan 2004 10:38:28 +0100 Content-Transfer-Encoding: 7bit Sender: gnome-vfs-list-admin@gnome.org Errors-To: gnome-vfs-list-admin@gnome.org X-BeenThere: gnome-vfs-list@gnome.org X-Loop: gnome-vfs-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion about gnome-vfs and gnome-vfs modules List-Unsubscribe: , List-Archive: On Fri, 2004-01-30 at 10:10, Christophe Fergeau wrote: > > By the way, as my previous patch against the nntp method was not > > reviewed, could you tell me if this list is the right place to send > > patches, or if a bug report is a better way. > > I prefer having a bug report in addition to mails since I regularly > check the pending bugs in bugzilla, and process them as I find time. My two patches (nttp and ftp/http leaks) are filed as bugs #132950 and #132951 regards, Thomas.