Re: [Freedos-devel] BtrFS filesystem in FreeDOS
Q:what opttions were used to get DOSLFN to work with what version of FREEDOS? Q:were there any other required drivers to be im place? Q:what did config.sys and autoexec.bat look like? Jim Michaels > > From: Rugxulo >To: freedos-devel@lists.sourceforge.net >Sent: Wednesday, July 18, 2012 3:39 PM >Subject: Re: [Freedos-devel] BtrFS filesystem in FreeDOS > > >Hi, > >On Wed, Jul 18, 2012 at 5:32 PM, Ralf A. Quint wrote: >> At 03:22 PM 7/18/2012, sergei karhof wrote: >> >>>It's strange, because the LEAN filesystem was designed to work on >>>FreeDOS-32, which is a DOS too, judging by the name. Can someone >>>explain the incongruence. BTW, is FreeDOS-32 dead or what? >> >> IMHO, it was dead right from the start, as those folks that started >> it didn't have a clue on what they would get them self into. >> You can simply not create a 32bit OS that is still compatible with >> DOS, you will end up writing a complete new (and different OS)... > >A few years ago, one of the main developers left (for various reasons, >e.g. preference for different licensing). So the few others haven't >really done much since (except for a sporadic LEANfs add-on >documentation or whatever-the-heck it is). > >>>What I was would be willing to settle for, eventually, is ANY >>>filesystem with extended attributes that can be used from within >>>(Free)DOS. But from what you have told me the prospects do not seem >>>very bright right now... :( >> >> The DOS file system is FAT(16/32). DOS is based upon this, even long >> file names on FAT32 are a crutch shoe horned into it to still be >> partially compatible. > >DOSLFN still works pretty well, so we can't complain too hard. >(Patents expiring in 2017 ftw!!!) > >> Considering that there are no DOS application that can handle things >> like "Extended Attributes", what is the purpose of trying to use it with DOS? >> >> IMHO people should use DOS the way it was designed (and working for >> decades) instead of continuously trying to turn it into the second >> coming of Linux or the like... > >Still, I don't think it's a horrible idea to add another file system, >but outside of paying someone (e.g. Ben Lunt, assuming he'd even have >time or interest), I don't see how it can be done. > >Even userland things like Odi's LFN Tools and LTOOLS don't work for >me. So I dunno. And yes, at one time I thought HPFS would be cool to >somehow enable for FreeDOS (esp. since OS/2 used it). > >Or maybe some of us (??) should focus on a DOSEMU-only ttyLinux >distro. At least that would have some built-in support for other file >systems, if you really needed reliability or speed or whatever. (But >it feels like a lot of work, blech.) > >Alas, there's always more to do. :-P > >-- >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 > > >-- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
>> That depends on whether you'd consider MSW 3.x or 4.x respectively to >> constitute a "complete new and different OS" on top of MS-DOS =P > > What is MSW? Does this help?: http://www.google.com/search?q=MSW+4.x+%22MS-DOS%22+DOS+kernel Basically an abbreviation that doesn't suggest some sort of "Win". >> Well, at least as far as I understood it, FreeDOS-32 did aim for >> something >> similar - specifically, running the new (FreeDOS-32) kernel in protected >> mode, and ultimately allowing to run virtual(ised) machines for (V)86M >> DOS >> compatibility similar to regular tasks in that system (as well as DPMI >> or >> native applications, or potentially others). > > Sounds easy, but people seem to forget the problems with all DOS > internal structures and calls/interrupts being 16bit real mode, this > would be a far from trivial task. Even DOS extenders have already > quite a hell of a time to stay compatible with that... DOS extenders are something entirely different (API translation from one mode to another). Virtualisation and even full emulation are relatively 'easy' to implement on current machines (because of their performance), though some work is still necessary. To allow multiple tasks to access the same physical resources, some abstraction is needed of course, such as using a redirector-like interface for file system access within the task and handling the calls from this interface by passing them to the actual file system drivers (which necessarily must implement workable file locking semantics, unlike the typical expectation for DOS systems that do not explicitly multi-task). Or accessing a file system image instead of an actual file system, where each image is typically associated with no more than one running task. Both of these methods are provided by DOSBox and dosemu, the former is employed by NTVDM, the latter is generally provided by emulators. (If memory serves, DOSBox unfortunately provides high-level file system redirection only within its integrated DOS, which itself is a bad choice for other reasons.) >> DOS, however, allows external file system drivers to (relatively >> speaking) >> easily integrate into the kernel as redirectors. (As mentioned, a >> consistent LFN extension has not yet been defined for the redirector >> interface.) The roots of this go back to MS-DOS 3.x and the redirector >> interface has been used (provided) ever since by various networking >> clients as well as *CDEX programs, as well as more 'exotic' file system >> drivers. > > But you can't use the redirector interface really for any file system > running on DOS itself, Depends on your definitions. If you mean "local" (on that same machine, and running on that DOS): The file systems of a *CDEX driver are "local", and eg iHPFS also accesses "local" file systems from hard disk partitions. > not to mention that on the receiving end > (DOS), you still have all the inherited limitation of DOS. Different > character representations are just a start here (256/512 bytes code > pages compared to UTF8/16/etc)... Yes, no one doubted that these restrictions are still carried along (specifically those concerning naming). 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
At 04:13 PM 7/18/2012, sergei karhof wrote: >On Thu, Jul 19, 2012 at 12:32 AM, Ralf A. Quint wrote: > > > Considering that there are no DOS application that can handle things > > like "Extended Attributes", what is the purpose of trying to use > it with DOS? > >The fact that there are no applications using it in DOS is a >*consequence* of the fact that it is not available. There would >certainly be applications using it, if only it were available. As for >the purpose of having extended attributes, it is the same purpose for >which it was introduced in other operating systems: they are useful. But why then not use an OS that has such useful features already available? When people are trying to force things like this on DOS, it always reminds me of hauling bricks with a Topolino... Ralf -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
At 03:57 PM 7/18/2012, C. Masloch wrote: > >> BTW, is FreeDOS-32 dead or what? > > > > IMHO, it was dead right from the start, as those folks that started > > it didn't have a clue on what they would get them self into. > > You can simply not create a 32bit OS that is still compatible with > > DOS, you will end up writing a complete new (and different OS)... > >That depends on whether you'd consider MSW 3.x or 4.x respectively to >constitute a "complete new and different OS" on top of MS-DOS =P What is MSW? >Well, at least as far as I understood it, FreeDOS-32 did aim for something >similar - specifically, running the new (FreeDOS-32) kernel in protected >mode, and ultimately allowing to run virtual(ised) machines for (V)86M DOS >compatibility similar to regular tasks in that system (as well as DPMI or >native applications, or potentially others). Sounds easy, but people seem to forget the problems with all DOS internal structures and calls/interrupts being 16bit real mode, this would be a far from trivial task. Even DOS extenders have already quite a hell of a time to stay compatible with that... >DOS, however, allows external file system drivers to (relatively speaking) >easily integrate into the kernel as redirectors. (As mentioned, a >consistent LFN extension has not yet been defined for the redirector >interface.) The roots of this go back to MS-DOS 3.x and the redirector >interface has been used (provided) ever since by various networking >clients as well as *CDEX programs, as well as more 'exotic' file system >drivers. But you can't use the redirector interface really for any file system running on DOS itself, not to mention that on the receiving end (DOS), you still have all the inherited limitation of DOS. Different character representations are just a start here (256/512 bytes code pages compared to UTF8/16/etc)... >So while you are certainly right in saying that DOS's (native) file >systems are the classic FAT FS family, there is also limited support for >extensions. (Not to mention that even before such support was available, >Netware clients apparently just intercepted applications' calls to the >high-level DOS API without any special help - certainly more complicated >to implement, of course. Same as what redirectors currently have to do to >support LFNs.) "limited" is the essential point here. And Netware was from the start developed with compatibility/communication to DOS in mind. And you were still restricted with your standard applications to DOS naming conventions. Ralf -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
At 03:39 PM 7/18/2012, Rugxulo wrote: >A few years ago, one of the main developers left (for various reasons, >e.g. preference for different licensing). So the few others haven't >really done much since (except for a sporadic LEANfs add-on >documentation or whatever-the-heck it is). Even without anyone leaving the project, I doubt that they would have ended up with anything usable... >Still, I don't think it's a horrible idea to add another file system, >but outside of paying someone (e.g. Ben Lunt, assuming he'd even have >time or interest), I don't see how it can be done. And once you have such a file system, what are you going to do with it? Ralf -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
On Thu, Jul 19, 2012 at 12:32 AM, Ralf A. Quint wrote: > Considering that there are no DOS application that can handle things > like "Extended Attributes", what is the purpose of trying to use it with DOS? The fact that there are no applications using it in DOS is a *consequence* of the fact that it is not available. There would certainly be applications using it, if only it were available. As for the purpose of having extended attributes, it is the same purpose for which it was introduced in other operating systems: they are useful. -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
>> BTW, is FreeDOS-32 dead or what? > > IMHO, it was dead right from the start, as those folks that started > it didn't have a clue on what they would get them self into. > You can simply not create a 32bit OS that is still compatible with > DOS, you will end up writing a complete new (and different OS)... That depends on whether you'd consider MSW 3.x or 4.x respectively to constitute a "complete new and different OS" on top of MS-DOS =P Well, at least as far as I understood it, FreeDOS-32 did aim for something similar - specifically, running the new (FreeDOS-32) kernel in protected mode, and ultimately allowing to run virtual(ised) machines for (V)86M DOS compatibility similar to regular tasks in that system (as well as DPMI or native applications, or potentially others). About compatibility however, naturally emulating and/or virtualising a system might not provide sufficient compatibility, depending on the quality of the implementation and the amount of performance available. This is already evident with all the *EMM386s, which do run the original system software in V86 mode (though to my knowledge still entirely single-tasked), and sometimes cause incompatibilities. > The DOS file system is FAT(16/32). DOS is based upon this, even long > file names on FAT32 are a crutch shoe horned into it to still be > partially compatible. DOS, however, allows external file system drivers to (relatively speaking) easily integrate into the kernel as redirectors. (As mentioned, a consistent LFN extension has not yet been defined for the redirector interface.) The roots of this go back to MS-DOS 3.x and the redirector interface has been used (provided) ever since by various networking clients as well as *CDEX programs, as well as more 'exotic' file system drivers. So while you are certainly right in saying that DOS's (native) file systems are the classic FAT FS family, there is also limited support for extensions. (Not to mention that even before such support was available, Netware clients apparently just intercepted applications' calls to the high-level DOS API without any special help - certainly more complicated to implement, of course. Same as what redirectors currently have to do to support LFNs.) 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
> With regard to modern filesystems, the intrinsic limitations that you > and the previous poster pointed out seem to rule out the LEAN > filesystem as well. Am I right in my inference? LEAN's internal structures are designed to be simple, so writing a (slow) driver that uses little memory to access it should be possible. However, it doesn't store/honour short name aliases either, so the long name difficulty is essentially the same. The lack of DOS interface support (eg for extended attributes) is also the same, though LEAN FS itself does potentially provide some permissions and ownership numbers, more precise timestamps, and some form of extended attributes. (See the current specification for details.) > It's strange, because the LEAN filesystem was designed to work on > FreeDOS-32, which is a DOS too, judging by the name. Can someone > explain the incongruence. Yeah, that might be a bit misleading. The FreeDOS-32 kernel runs in protected mode and is an entirely different thing from the FreeDOS kernel (which runs in V86 or real-address mode). Additionally, DOS (SFN) compatibility was not yet considered in the LEAN FS design - though it is still being extended from time to time. (Storing SFN aliases within an extension to the current directory entry format would be trivial, but all drivers should then be required to honour such existing aliases (even if they don't create aliases themselves) - to avoid creating a native/long name exactly matching that alias.) > BTW, is FreeDOS-32 dead or what? It hasn't seen a lot of development in recent years. The most recent major update (0.6.0) to the LEAN FS specification itself was released on 2010-03-22, with the most recent minor update (0.6.1) on 2011-04-09. No idea when the actual FreeDOS-32 code was last touched. > What I was would be willing to settle for, eventually, is ANY > filesystem with extended attributes that can be used from within > (Free)DOS. But from what you have told me the prospects do not seem > very bright right now... :( Well, you could design the required interface extensions and then implement the drivers to conform to those =) Other than that, yeah, seems 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
Hi, On Wed, Jul 18, 2012 at 5:32 PM, Ralf A. Quint wrote: > At 03:22 PM 7/18/2012, sergei karhof wrote: > >>It's strange, because the LEAN filesystem was designed to work on >>FreeDOS-32, which is a DOS too, judging by the name. Can someone >>explain the incongruence. BTW, is FreeDOS-32 dead or what? > > IMHO, it was dead right from the start, as those folks that started > it didn't have a clue on what they would get them self into. > You can simply not create a 32bit OS that is still compatible with > DOS, you will end up writing a complete new (and different OS)... A few years ago, one of the main developers left (for various reasons, e.g. preference for different licensing). So the few others haven't really done much since (except for a sporadic LEANfs add-on documentation or whatever-the-heck it is). >>What I was would be willing to settle for, eventually, is ANY >>filesystem with extended attributes that can be used from within >>(Free)DOS. But from what you have told me the prospects do not seem >>very bright right now... :( > > The DOS file system is FAT(16/32). DOS is based upon this, even long > file names on FAT32 are a crutch shoe horned into it to still be > partially compatible. DOSLFN still works pretty well, so we can't complain too hard. (Patents expiring in 2017 ftw!!!) > Considering that there are no DOS application that can handle things > like "Extended Attributes", what is the purpose of trying to use it with DOS? > > IMHO people should use DOS the way it was designed (and working for > decades) instead of continuously trying to turn it into the second > coming of Linux or the like... Still, I don't think it's a horrible idea to add another file system, but outside of paying someone (e.g. Ben Lunt, assuming he'd even have time or interest), I don't see how it can be done. Even userland things like Odi's LFN Tools and LTOOLS don't work for me. So I dunno. And yes, at one time I thought HPFS would be cool to somehow enable for FreeDOS (esp. since OS/2 used it). Or maybe some of us (??) should focus on a DOSEMU-only ttyLinux distro. At least that would have some built-in support for other file systems, if you really needed reliability or speed or whatever. (But it feels like a lot of work, blech.) Alas, there's always more to do. :-P -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
At 03:22 PM 7/18/2012, sergei karhof wrote: >It's strange, because the LEAN filesystem was designed to work on >FreeDOS-32, which is a DOS too, judging by the name. Can someone >explain the incongruence. BTW, is FreeDOS-32 dead or what? IMHO, it was dead right from the start, as those folks that started it didn't have a clue on what they would get them self into. You can simply not create a 32bit OS that is still compatible with DOS, you will end up writing a complete new (and different OS)... >What I was would be willing to settle for, eventually, is ANY >filesystem with extended attributes that can be used from within >(Free)DOS. But from what you have told me the prospects do not seem >very bright right now... :( The DOS file system is FAT(16/32). DOS is based upon this, even long file names on FAT32 are a crutch shoe horned into it to still be partially compatible. Considering that there are no DOS application that can handle things like "Extended Attributes", what is the purpose of trying to use it with DOS? IMHO people should use DOS the way it was designed (and working for decades) instead of continuously trying to turn it into the second coming of Linux or the like... Ralf -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
On Wed, Jul 18, 2012 at 11:52 PM, Jim Hall wrote: > In Unix systems, the filename can be a short letter to grandma. > For example, I just created these two 1-line files in my DOSEmu > directory: > > $ ls -sk D* > 4 Dear Grandma, I hope you are fine. I am fine too. Tomorrow, we are > going on a boating trip. I think it will be fun. Will write again > soon. -me > 4 Dear Grandma, I hope you are fine. I am fine too. We had a lot of > fun on the boating trip. Next week, I hope to try skydiving and > lion-taming. Will write again soon. -me LOL. I like your sense of humour, Jim. With regard to modern filesystems, the intrinsic limitations that you and the previous poster pointed out seem to rule out the LEAN filesystem as well. Am I right in my inference? It's strange, because the LEAN filesystem was designed to work on FreeDOS-32, which is a DOS too, judging by the name. Can someone explain the incongruence. BTW, is FreeDOS-32 dead or what? What I was would be willing to settle for, eventually, is ANY filesystem with extended attributes that can be used from within (Free)DOS. But from what you have told me the prospects do not seem very bright right now... :( -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
> I think the big limitation will be addressable filesystem space. Btrfs > can support 2^64 files, and 16EB volumes. That's a wee bit too much > for DOS to handle. > > Even if you have a Btrfs that's fairly small, say small enough to be > addressable by DOS, Assuming the driver has enough space for its internal tables, the redirector file system interface has no direct restrictions on the number of files, or on low-level details of a file system such as how many 'sectors' or 'clusters' or 'blocks' of whatever size it has. However, the regular SFT implementation allows only up to 255 simultaneously opened file handles (including the three handles typically referring to CON, AUX, and PRN for the first five 'std' handles). Additionally, file sizes are limited to 4 GiB (or only 2 GiB even, in some implementations) unless SFTs and APIs are extended to eg 64-bit seek offsets (as implemented by EDR-DOS). Like LFNs, the 64-bit seek offsets are not supported on the regular redirector interface, so a file system driver would have to work around that additionally (similar to providing LFNs manually), or extensions to that interface are necessary as well. (I don't think EDR-DOS defines such an extension as of yet?) > you have the long filename problem. Yes, as mentioned. > DOSEmu presents a local Linux folder as a drive to FreeDOS, using > long-to-short filename conversion. So I can see these files in > FreeDOS, but they have different names: > > DEARG~10.-ME > DEARG~LC.-ME Oh, doesn't its redirector driver provide long names on the LFN API? > So you can do it, but the challenge is making these files addressable > by DOS in short namespace, in a user-accessible way. Yes, as I hinted at, it is particularly difficult because it doesn't suffice to just dynamically shorten each name _individually_ as then the same short name alias might be invented twice in the same directory. Such conflicts must be avoided; otherwise (at best) the duplicate name will actually access only one of the files. 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
> 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.) > I think the big limitation will be addressable filesystem space. Btrfs can support 2^64 files, and 16EB volumes. That's a wee bit too much for DOS to handle. Even if you have a Btrfs that's fairly small, say small enough to be addressable by DOS, you have the long filename problem. In Unix systems, the filename can be a short letter to grandma. For example, I just created these two 1-line files in my DOSEmu directory: $ ls -sk D* 4 Dear Grandma, I hope you are fine. I am fine too. Tomorrow, we are going on a boating trip. I think it will be fun. Will write again soon. -me 4 Dear Grandma, I hope you are fine. I am fine too. We had a lot of fun on the boating trip. Next week, I hope to try skydiving and lion-taming. Will write again soon. -me DOSEmu presents a local Linux folder as a drive to FreeDOS, using long-to-short filename conversion. So I can see these files in FreeDOS, but they have different names: DEARG~10.-ME DEARG~LC.-ME Granted, that's a very extreme example, but you get the idea that a long filename gets munged into 5 visible characters, a hash value, and the extension. It's a similar method with other long-to-short filename mapping schemes. Workable for some folks, but even if I applied this 5-character rule to my ~/Documents directory on Linux the names get very hard to read: 2011E~12.PDF ALUMN~12.PDF CALIB~12 CC50_~12.MOB CIORE~12.PDF CONFI~12.PDF D12-0~12.PDF DATAB~12.KDB DOCTO~12 E-MAI~12.PPT ERS11~12.PDF ERS11~34.PDF INSTA~12 So you can do it, but the challenge is making these files addressable by DOS in short namespace, in a user-accessible way. -jh -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
> 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
On Wed, Jul 18, 2012 at 2:39 PM, Geraldo Netto wrote: > Hi Serg! > > Unfortunately (AFAIK) FreeDOS cannot handle it > once there are many differencies between linux and freedos at low level > > Can`t you use any kind of cd/usb linux? > i myself use system rescue cd > http://www.sysresccd.org/ Actually I am not in need of a system rescue software. I was only mentioning it as an example of how a BtrFS filesystem driver could be useful. Indeed, with the growing popularity of BtrFS there will be many other uses. -- 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
Re: [Freedos-devel] BtrFS filesystem in FreeDOS
Hi Serg! Unfortunately (AFAIK) FreeDOS cannot handle it once there are many differencies between linux and freedos at low level Can`t you use any kind of cd/usb linux? i myself use system rescue cd http://www.sysresccd.org/ People will suggest others :P Kind Regards and Best Wishes, Geraldo Netto Non dvcor, dvco => Sapere Aude São Paulo, Brasil, -3gmt site: http://exdev.sf.net/ On 18 July 2012 09:22, sergei karhof wrote: > Hi everyone, > > what are the chances of seeing a FreeDOS driver for the BtrFS > filesystem anytime soon? > > 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. 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). > > Is anyone planning to work on it? > > Thanks > > Serg > > -- > 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 -- 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
[Freedos-devel] BtrFS filesystem in FreeDOS
Hi everyone, what are the chances of seeing a FreeDOS driver for the BtrFS filesystem anytime soon? 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. 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). Is anyone planning to work on it? Thanks Serg -- 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
