[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FAT/Minix conversion
On Fri, 4 Aug 1995, Evan Langlois wrote:
Hi!
> The fat drive would have access 660 for all files, and 770 for all
> directories. The FAT/DOS attributes would be parsed to modify this:
> READ-ONLY AND 220
> SYSTEM AND 700
>
> Also, Executable programs (ending in .sh, .prg, .tos, .ttp, .app, .gtp)
> should have the extension stripped, and the mask OR'd with 110. A file
I don't think it's a very good idea to strip the extensions because some
programs rely on that - for example GEMINI won't start any program
without extension because it doesn't look at the extended attributes.
Other than that, you can exactly say what type a program (GEM, TOS) is if
you it as icon or in the directory listing. It's not like Unix where a
program can (although it should not) use both terminal and graphical
functions. I think the AES doesn't like GEM programs started from a
command line, does it?
> marked as HIDDEN should have the regular extension concatenated to the
> filename with a dot (.) prefixed to the filename. So a hidden file
> named "PROFILE" becomes ".profile" (all filenames from a FAT system should
This is OK. It would make porting unix software while using a TOSFS much
easier.
> be converted to lowercase), and a hidden "SCREEN.RC" becomes ".screenrc".
How would you delete the last dot? Scan for 'rc' or something? It should
not go that far - I think '.screen.rc' is enough and much easier.
> Doing this in the TOSFS driver instead of the library would make things
Isn't there anybody that wants to write a new TOSFS driver as .xfs?
> Unix/Minix filenames should also be parsed this way. All access
> permissions should apply as normal and be used from the drive, no matter
> what the process domain, but a file where a particular user does
> not have access could be marked as SYSTEM + READONLY (but don't let the
> user actually read the file, of course) to TOS domain programs, while
> those with only a r-- access to that file would have a TOS attribute
Seems to be a good idea. Although I don't think that the SYSTEM flag is
meant to be used like that - but who cares.. :-)
But this has to be changed in the MinixFS.
> of READ-ONLY. Files that have a executable permission would automatically
> have a .ttp attached, or maybe .prg (any ideas on how to make the desktop
If anything, then .ttp. GEM programs should keep their extensions,
because they are more likely to be started directly from the user over a
shell. E.g. NeXTStep applications have an extension of .app,
although it is a unix system and it also has programs without extension.
> recognize which is a GEM program and which is not)? I think all programs
> run from the desktop should have stdin and stdout routed to a pipe,
> and then pretend its a GEM program - if there is IO on that pipe (reroute
> BIOS too) then open a window manager to handle the IO automatically. Then
> a bad GEM program wouldn't put TOS text on the screen anymore - and you
> wouldn't have any differences between the .TTP and the .PRG programs (and
> you'd be a mint domain process that looked at the --x bit anyway).
>
> Minix files that begin with a dot (.) could be marked as HIDDEN (and drop
> the dot), and maybe kludge it to recognize files that end with certain
> characters as the extension. So, for example, ".screenrc" would look
> like "SCREEN.RC" with HIDDEN set to a TOS domain process. Convert the
> filenames to all upper-case for TOS domain programs, and TOS domain
> should NOT be case sensitive! Also, the LAST 3 characters of a filename
^^^
You can't do that on minix partitions. What if you have 'makefile' and
'Makefile'? It would depend on the sequence of the files which you get
with your TOS domain editor. But if you have a good fileselector, and the
editor at least does not change the filename's case, you could edit
both files.
> should be the extension, don't just truncate (I think some versions
> of minix truncate it, so that reallybigfile.tgz becomes REALLYBI.GFI,
> when it should be REALLYBI.TGZ - I'm not exactly sure if that is the
> way Minix handles it or not though).
>
> Also, how do I give a user access to more than one group? What if I want
> to a user access to 5 or 6 groups?
You just type the user names after the group names in /etc/group.
E.g. a line like
other:*:20:evan,stephan
means that the users evan and stephan have the supplementary group
'other' in addition to the group that is given in /etc/passwd. The login
program should then initialize these groups when someone logs in.
> Anyone like these ideas? If so I might try hacking them into TOSFS
> and digging around for the MINIXFS sources. I'd rather get feedback first,
> and then maybe talk some enthusiastic<sp?> and more experienced person
BTW, there seems to be less enthusiasm than a few months ago? Is it just
the summer?
> into making the changes <grin>.
>
> CYA,
> Evan Langlois
> ekl@sdf.lonestar.org
Ciao,
Stephan
-----------------------------------------------------------
Stephan Haslbeck
Student of Computer Science, Technical University of Munich
std mail: Agricolastr. 61, D-80686 Muenchen
email: haslbecs@informatik.tu-muenchen.de
-----------------------------------------------------------
Es gibt keine Probleme, nur Loesungen.
-----------------------------------------------------------