>> But I'm not so sure that we need support for such beast in kernel.
>> IMO better to implement userspace library with albod support and
>> then [if all will work as desired] pull some time-critical parts
>> in kernel.
> The userspace version already exists. It is called a compound document
> file or structured storage. Users with large image-laden documents
> tend to have performance problems. Users are forced to work around
> the problem. (by putting each chapter of a book in a separate file)
It's beast used in MS Office ? Where you can send you password with document
against you will ? No, thnx.
>>From userspace, you only get the performance by using directories.
> See my response to Theodore Y. Ts'o for why this is broken.
Can not find it... But may be it's still in wires somewhere...
>> I seen few messages with compains against such way: `One must be
>> able to "rm" or "mv" the whole document with any old tool. That
>> really ought to include old statically linked tools. ... I'll
>> expect to _not_ see "magic" file names in directories. I'll also
>> expect something that the NTFS driver can use.' but I'm noot seen
>> rationales under such complains.
>>
>> Why it "really ought to include old statically linked tools" ?
>> Do you really have that many and why you can not recompile them ?
> Some people still use libc 4. Some people have commercial software.
> Some people have lost their source code.
Now what ? It's still minority and thay will need to do something eventually...
Thay can just avoid new programs based on albods for now. Not a big deal.
We are not M$ and compatibility is not a fetish here...
> Userspace should not suddenly break.
Not suddenly. After installation of new library needed for GNOME 3.8 :-))
Usual story, not something really new or unexpected. And if library contains
BIG FAT WARNING (like glibc 2.1, for example :-) I can not see problems.
>> Why you expect to _not_ see "magic" file names in directories ?
> That was the only thing they could do from userspace, and it stinks.
> It is a slow and unreliable way to identify a compound document.
Slow -- may be. Unreliable... Why ? Collizions ? Use some UUID as magic
file name ...
>> And you'll see "magic" names related to albod handling only when
>> compatibility libraries are noty preloaded anyway.
> So, what happens if the hidden name is ".albod" and my software
> tries to use ".albod" as the name of a document component?
Some error will be returned :-) Not a big deal: there are no programs to work
with albods yet, so it's not a problem to have forbidden name (or may be even
names).
>> And why expect something brain-dead enough to support "MS way" on NTFS ?
> Sorry, but Microsoft isn't going to just go away any time soon.
> Most of the world has to deal with Windows tools, Windows clients,
> and Windows filesystems. It will take a _minimum_ of 20 years for
> the world to get rid of Microsoft.
Correct. And now what ? If you want perfect support for Microsoft crap
then use Micosoft's OS, not Linux. Yes, we want to support Windows tools,
Windows clients and Windows filesystems in Linux. But ONLY when it does
not requires changes in non-related to such exchange subsystems. So no,
support for reparse points does not look like requirement. If it's really
needed for something that such support should be added in NTFS driver, not
in some other subsystem.
-
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/