> what are the chances of seeing a FreeDOS driver for the BtrFS > filesystem anytime soon?
I don't think it will happen. > As many of you may already know, BtrFS is poised to become the next > Linux standard filesystem very soon, replacing the ext family of > filesystems. I don't even know of any recent FreeDOS development on any extFS drivers. The following lists two projects allowing some ext2/3 access via command line tools (not actual file system integration!): http://tldp.org/HOWTO/Filesystems-HOWTO-6.html > BtrFS is really good, and is getting better and better. > > It would be really, really nice to have a FreeDOS driver for it, so at > the very least we would be able to access BtrFS volumes (for instance, > for maintenance and repair). (Free)DOS isn't particularly well-suited for this, because its (current) high-level file system API doesn't even have concepts such as unix-like permissions or owners or hard links or soft links or ACLs or extended attributes etc. Additionally, it wants all files to have short names (which naturally aren't available on ext or BtrFS) and expects these short names to be stored in all-caps and there is hardly any international character set support. These name/path restrictions are partially lifted by the LFN API (which the FreeDOS kernel doesn't support natively) but intercepting and handling LFN API calls in a DOS redirector file system driver is rather complicated (because the regular redirector interface only supports the SFN API). If a driver shows some or all files and directories only on the LFN API, LFN-unaware programs won't be able to access these files and directories. Hence, typically DOS redirector file system drivers for file systems without short names dynamically invent short names on their own, hopefully without conflicts. (SHSUCDEX apparently does this, but this might be more difficult to achieve well in a read-write driver.) And then, of course, regular 86 DOS software is restricted to just under 1088 KiB of directly addressable memory. This could probably be lifted by developing the driver as resident DPMI client, or DPMS client, or JLM, or (maybe) employing VCPI. > Is anyone planning to work on it? Very unlikely. Regards, Chris ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
