>>> b. thay must index files by full names.
>> Like the other respondant, I don't understand what you mean.
> So I am :-(
Sorry.
I am talking about fast file type determination in userspace.
Scanning file headers each time is slow.
The only possible solution I see is cache:
type = get_file_type_from_cache( key );
Here the key (index) may be only full path name,
since UNIX does not use file extensions
and inodes are not invariant for files.
Moreover, such cache must be stored in external (for FS)
database (unlike symlinks in ext2).
I.e. it will:
1. duplicate names of all files on the computer,
2. pull drive heads.
I.e. it will be large and slow.
> 0.82user 0.06system 0:00.92elapsed 95%CPU (0avgtext+0avgdata
0maxresident)k
> 0inputs+0outputs (1146major+176minor)pagefaults 0swaps
> Doesn't look like "seconds" to me. Looks like less than a second.
> This also doesn't mean the 'file' could not be optimized.
While you created these files, they were defragmented and cached.
In real situation you'll get some seconds.
>> a. What is simpler: one powerful mechanism or 100 simple mechanisms?
> I haven't seen anyone propose 100 simple mechanisms. I proposed (1)
> common library for applications, and (1) general kernel mechanism for
ACLs
Let me call to (my) 'file types' problem - "first problem".
Then ACLs will be second. And so along.
>> b. What simpler kernel mechanism?
>> If you store somewhere additional data - you must rewrite mv, aren't
you?
> Earlier you said that userspace programs could not handle this concept.
> Now you are complaining that mv would have to be rewritten if you
> DON'T (as in DO NOT) put resource fork capabilities in the kernel?
Pay attention: "... simpler *kernel* mechanism".
As I said:
1. Security can not be implemented in userspace.
2. mv have to be rewritten if you implement ACLs in ANY concept.
>> c. logging dynamic data.
> Don't have a clue what you mean here.
For example updating recent directories list.
Best regards
Alexander
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/