Tim wrote: > Tim: >>> I still think it'd be better to change the mechanism for how files are >>> saved, so it's fixed at the right moment. Having to have something >>> always assessing the drive, it just doing more work, continuously. We >>> could end up with a never ending procession of file preening daemons >>> running all the time, otherwise (locate, plus update, plus...). > > > Mikkel L. Ellertson: >> Please explain what you mean. Where are you saying the change should >> be made? Where are you coming up with something always accessing the >> drive? > > In your system, you need a third party program managing things. Until > it's done its trick, you can't make use of the feature (like trying to > use locate before the database has been updated). You always have to > have some task periodically scanning your drive, just in case there's > something that needs typing. The contents of your drive aren't "just > there for use at all times". > No - the third party program is only for programs that do not set the mime-type themselves. When looking at a file, it would first check to see if the mime-type was set, and if so, do nothing. Only if the type is not set would it do something. You could also limit it to specific directories trees, or range of dates, if you wanted. >> Are you saying that the system should check every file as it is >> being saved, and set the mime-type, instead of letting the >> application that creates the file do it? Granted, this would do away >> with having any kind of cleanup cron job being run, but it would add >> overhead to saving every file. You still have the problem of how to >> handle files that do not have a "magic number". > > Better to assess one file on the way through to the drive, once, rather > than have to assess every file as something scans through the > collection. That overhead ought to be minimal in comparison. And you > have the ability to either have that handle every file save, or not > bother to interrupt file saves from programs which sets the type. > You would not have to assess every file. You would have to pull up the directory entry, and see if the mime-type bits are set. If it is, move on the the next entry. > Program saves a file and sets the type itself, the file typer does > nothing. Program saves a file without setting a type, the file typer > meddles with the file save. > The idea sounds nice, until you start thinking about the amount of code you are adding to the file save process. If the mime-type is set, then it is no big deal - a small addition to the SE Linux code. If it isn't set, then you have to try and determine the mime-type. This is better handled by a user-space program then as part of the file system module. This is especially true because the list of mime-types in not fixed. The added processing time would probably not be too bad for a single file, but what happens when you are doing a restore from a backup media that does not support ACLs? There are other things to be worked out as well - how do we handle the mime-type/ACL mapping? It would be nice to have the same mapping on all systems. A list of common mime-types and their mappings, with some reserved for local use? Submit requests for a mime-type number when you need to create a new mime-type? Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
