Go to the FreeLists Home Page Home Signup Help Login
 



[openbeos] || [Date Prev] [01-2005 Date Index] [Date Next] || [Thread Prev] [01-2005 Thread Index] [Thread Next]

[openbeos] Re: kernel mime_table module

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Tue, 04 Jan 2005 21:35:33 +0100 CET
"shatty" <shatty@xxxxxxxxxxxxx> wrote:
> I am also a bit concerned about a large folder
> performance.  BFS conveniently caches the type
> after a file has gone through the somewhat
> expensive sniff/identify process.
> 
> For FAT32 I wonder if we could use a file in the 
> directory as a cache.  If we used one of those
> magic names like "Desktop.ini" it wouldn't show up
> when browsing from the OtherOS.  It would use some 
> space on the other file system and this option is
> not available for read-only media.

This would work for writable file systems, but it would need to be 
rebuild from time to time to pick up changes made in other OSs (you 
wouldn't normally think so, since those usually determine the file type 
upon file extension only - but who knows).

It's also not so nice to clobber shared directories from other systems 
by default -- it's also difficult to use a hidden file name in that 
case, since, for example SMB shares can come from almost every other 
system which may have different rules here.
That's also a problem with FAT32, since this one can be read by many 
different systems.

> In fact, Joliet CDs are a real nuisance for 
> determining types because the access time is
> quite slow as well.  They are just about the
> worst performing case for this task.

Slow media like CDs are a good reason why the file type should be 
determined by extension only for those file systems.

Bye,
   Axel.






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.