On Wed, 2002-01-30 at 16:28, Bart Oldeman wrote: > This should make no difference since flock(2) operates at a higher level.
Well, the "situation" is farther below. I'll let you recommend what I should do. > The reason why people use dosemu to access FAT partitions is that there > are a lot of dual boot systems which just happen to have DOS programs on > the FAT partitions. I can't see any other reasons (if lredir is used). Right. /var/lib/dosemu is actually its own filesystem (on purpose). So I can format it either Ext2/3 or FAT16/32. Again, the "situation" is below. > In that case it's different: the umask option from mount(8) is only a > mount option for FAT style filesystems. The _users_ umask (see > e.g. bash(1)) is what the user chooses it to be. If you want to force > umask 000 for dosemu sessions then that would be a simple script. > But the user can change the permissions outside dosemu. Yeah, I was going to use an alias. > You can make the directories sgid dosemu if you want to restrict > to a group. And use the "sticky bit" to make sure all new files are too. > But really dosemu operating on ext2 isn't any different than emacs > or any other Linux application operating on ext2. Well, here's my "situation": I need to run multiple instances of a program. This is, in fact, how it runs under "normal" DOS as well. You see, it is an accounting package, designed for a DR-DOS variant called Concurrent Multiuser DOS. It's basically a DPMI DOS running Task Manager where each DOS session is either on a "virtual console" or pumped to a serial port (and out to a terminal or PC running a software-based terminal emulator) c/o a multiport board. It's just a way to give other terminals/PCs access so the program "runs local" on one system. Again, the accounting package doesn't do anything fancy. It simply allows only one user to write to particular files, while others read or write to another file -- using standard DOS file access rules (e.g., one user can only use one module at a time, or open one table for write access simultaneously, etc...). The Multiuser DOS part just lets multiple instances of the program run in their own DPMI session, and allows them to be individually pumped over serial ports to different terminals/PCs where people do their input. What the vendor has been "pushing" (at a heafty price too!) is for people to dump the program and data on an SMB share (like a native Windows server) and run the DOS program under Windows on other Windows systems connected to that share. This is where all those "nasty" native Windows SMB-oplocks "performance crap by default" is destroying people's data. The vendor recommends various registry hacks to overcome the oplock issue, but the problem is with the native Windows SMB approach period IMHO. While I've shown the vendor how UNIX-based SaMBa services can "tame" this (because Samba allows per-share settings on oplocks -- e.g., you can totally disable them, which is what one should do in the case of this app! ;-), I still don't like the idea of sharing this application out on the network (and it's probably slower). That's where DOSEmu's XDos comes in beautifully! I can run multiple instances of DOSEmu+DRDOS on one system, just like I was running that Concurrent Multiuser DOS -- with all the file access on the same, local system (and not a network filesystem one with multiple clients!). And I can run multiple instances of the accounting app, one under each DOSEmu session, just like their Concurrent Multiuser DOS setup. Instead of serial connections to terminals though, I'm just setting XDos to display to a remote X-Server. I haven't fully tested this yet, but the application works fine under DOSEmu+DRDOS, including multiple instances on the same data set (although different files). I'm set on making the C: drive its own ~2GB filesystem, but am unsure how I should do it. - Ext2/3 mounted as /var/lib/dosemu (ledir C:), or - FAT16/32 mounted as /var/lib/dosemu (ledir C:) Your opinion? -- Bryan P.S. Thanx for all your help! I'm going to be writing up a technical whitepaper for the vendor on this. They are totally lost when I explain it to them. -- Bryan J. Smith, Engineer mailto:[EMAIL PROTECTED] AbsoluteValue Systems, Inc. http://www.linux-wlan.org SmithConcepts, Inc. http://www.SmithConcepts.com --------------------------------------------------------- 1999 IRS Data: The top 1% of income earners pay over 36% of the taxes, but have less than 20% of the total income. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
