it is the same problen as in linux : u need a ntfs driver, which I
thinks has not been ported to Minix

If I were to re-install Windows 2000 with the FAT or FAT32 filesystem,
would that make my life easier?

Thanks!
Chris

if u have FAT driver for minix, u will be able to access the partinion

crandall wrote:

> I have an 8 GB hard drive, currently with two partitions. The first
> partition (c0d0p0) has Windows 2000 installed. The second partition
> (c0d0p1) has MINIX 3.1.2. I'd like to mount my Windows partition (NTFS
> file system) for reading within MINIX. I can do this easily in Linux,
> but when I try to do the following in MINIX, I get an error (I am
> logged in as "root"):

Minix never has, and possibly never will have, the ability to mount
foreign file systems. It has in the past always been considered
a complication that would make it harder for Minix to be a simple
system for teaching OS principles.

Minix has always provided utilities for reading and writing
directories and files in foreign file systems. Originally there were
the dosdir/dosread/doswrite utilities for small FAT file systems; now
mtools can access larger FAT file systems. The isoinfo/isodir/isoread
utilities provide similar access to iso 9660 (CD-ROM) file systems.

In principle someone could write a set of ntdir/ntread/ntwrite
utilities, but NTFS is not an open standard, and has been a moving
target in the past.

You can install a new Windows XP system on a FAT partition but you
can't convert an existing NTFS system to FAT, and almost universally
new systems with Windows pre-installed come with Windows on an NTFS
file system. It is possible, with care and the right utilities, to
reduce the size of a Windows partition (you may have done this already
to make a Minix partition). The most practical way to exchange files
between Minix and a Windows system on the same machine is to make a
new small FAT partition that each OS can access, and use this as a
staging area for transferring files.

This should be in the FAQ... I know I've answered this one before. Well,
actually, it is there at http://www.minix3.org/doc/datxchng.html.
That page was first written back in the days before mtools was
available, when Minix could only access small FAT partitions. The
principle is the same.

--
+----------------------------------+
| Albert S. Woodhull |
| awoodhull@hampshire.edu |
| http://minix1.woodhull.com/asw/ |
+----------------------------------+
The idea is to die young as late as possible.

awoodhull@hampshire.edu wrote:
> Minix never has, and possibly never will have, the ability to mount
> foreign file systems. It has in the past always been considered
> a complication that would make it harder for Minix to be a simple
> system for teaching OS principles.

I'm surprised to hear this. I would have thought that in Minix 3 with
its micro-kernel design one would simply create a user-space FAT32,
ext2/3, UFS, NFS, or what ever file-system daemon to hook in the
necessary translation layer. I would have also thought this would be of
interest for teaching purposes too, since in a Windows centric world,
one needs to understand how to interoperate with other file systems in a
user friendly manner in order to move data around. I'm sure there are
many note worthy issues, particularly w.r.t. NFS and file locking.

--
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/

Anthony Howe wrote:
> awoodhull@hampshire.edu wrote:
> > Minix never [had], and possibly never will have, the ability to mount
> > foreign file systems.

> I'm surprised to hear this. I would have thought that in Minix 3 with
> its micro-kernel design one would simply create a user-space FAT32,
> ext2/3, UFS, NFS, or what ever file-system daemon to hook in the
> necessary translation layer.

I was being cautious when I said Minix possibly will never have the
ability to mount foreign file systems. It certainly should be possible
to do what you suggest. But the "hooking" might be somewhat
complicated. Ideally, once mounted, a foreign file system should not
appear to programs or the user to be different from a native file
system. From outside it looks simple. On the inside it is not so
simple.

> I would have also thought this would be of interest for teaching
> purposes too... I'm sure there are many note worthy issues,
> particularly w.r.t. NFS and file locking.

Agreed. But could this fit into a semester course, or into the
textbook for such a course? My guess is, that if such features were
added to Minix and I were working on creating an OSDI 4th edition
text, I would want to leave the foreign file system extensions out of
the "book version" of Minix. We have had to do this kind of thing on
many occasions already. For example, if you look at the source for the
book version of Minix 3 published in the new OSDI 3rd edition, you
will see that the files drivers/tty/pty.c and src/drivers/tty/rs232.c
are not present -- pseudoterminals and serial lines are not part of
the book version of Minix. Another example can be seen in
src/drivers/at_wini.c -- the full Minix release has a lot of code to
support reading CD-ROMs, but the book version was simplified by
leaving this out.

I don't want to discourage anyone from doing what you suggest. If I
were teaching an OS course using Minix and had an Honors or
Independent Study student looking for a project, foreign file support
would be a good possibility. I'd still suggest doing a standalone
xxdir/xxread/xxwrite utility for file system xx as a first step, but
once the basic problems of access were solved, mounting an xx
filesystem on Minix would be a logical next project.

--
+----------------------------------+
| Albert S. Woodhull |
| awoodhull@hampshire.edu |
| http://minix1.woodhull.com/asw/ |
+----------------------------------+
The idea is to die young as late as possible.

(Getting off-topic)

awoodhull@hampshire.edu wrote:
> Agreed. But could this fit into a semester course, or into the
> textbook for such a course? My guess is, that if such features were
> added to Minix and I were working on creating an OSDI 4th edition
> text, I would want to leave the foreign file system extensions out of
> the "book version" of Minix. We have had to do this kind of thing on
> many occasions already. For example, if you look at the source for the
> book version of Minix 3 published in the new OSDI 3rd edition, you
> will see that the files drivers/tty/pty.c and src/drivers/tty/rs232.c
> are not present -- pseudoterminals and serial lines are not part of

Speaking as someone who would buy such text books for self learning or
curiosity, its disappointing to hear of omissions from the book. I
bought the first Minix book way back when to study on my own and I would
not have if I had known it omitted topics.

I'm the sort of person that would want such a book to reflect what I
download on-line as much as possible. As a teacher, I'd just simply skip
certain chapters that are beyond the scope of the course, but then I'd
expect to have two or more courses that span the whole subject matter,
not just one.

I think its a disservice to those outside your realm of teaching to who
are interested in studying on their own with the aid of a text book as
much as possible. Maybe two editions of the book - one for teaching, one
more complete for the public? Don't like the idea of forking, but
completeness I think is important (and maybe fewer code listings in the
book in favour of on-line copies).

Anyway. I digress.

> the book version of Minix. Another example can be seen in
> src/drivers/at_wini.c -- the full Minix release has a lot of code to
> support reading CD-ROMs, but the book version was simplified by
> leaving this out.

:-(

--
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 AIM: SirWumpus Sendmail Milter Solutions
http://www.snert.com/ ICQ: 7116561 http://www.snertsoft.com/

On Wed, 31 May 2006 16:16:38 -0400, awoodhull wrote:
> I was being cautious when I said Minix possibly will never have the
> ability to mount foreign file systems. It certainly should be possible
> to do what you suggest. But the "hooking" might be somewhat
> complicated. Ideally, once mounted, a foreign file system should not
> appear to programs or the user to be different from a native file
> system. From outside it looks simple. On the inside it is not so
> simple.

I actually asked ast in a private mail a few weeks ago whether there would
be support for a VFS and here's the reply:

On Mon, 2006-05-15 at 20:11 +0000, Andy Tanenbaum wrote:
> We are looking at a VFS, but my initial inclination is not to
> support files systems that are not "UNIX-like" due to the complexity.
> What would be really nice, now that we have X, would be a graphical
> program for copying from a CD to the native file system. It could
> display the CD on the left and the native file system on the right
> and allow you to select a file and copy it. I think that would be
> good enough for most people and much simpler.

[I sent back a reply saying the following:
On Mon, 2006-05-15 at 20:28 +0100, Sitsofe Wheeler wrote:
> Certainly there's evidence that backs that up (userland VFS is popular
> in desktops like GNOME and KDE for network FSes like samba). I guess I
> hoped a CD FS would be good fit for a microkernel but obviously I don't
> know the amount of work it would take to implement yet (hey my C could
> do with the exercise...) and make transferring files at the command line
> easier.
]

ast followed up with this:
On Mon, 2006-05-15 at 21:35 +0000, Andy Tanenbaum wrote:
> As to VFS, I am trying to avoid bloat. I think the only thing anyone actually
> does with a CD is copy files from it (or burn files to it). I don't think
> there is a lot of demand for mounting them, really, just a better way to read
> them.

This is fairly consistent with what asw was saying. It won't be done for
bloat and complexity issues.

(Just an aside - if the book were any bigger I doubt I would get to the
end of it. I've been reading it in my spare time since February and I'm up
to P237 so far. Perhaps I should post errata queries to the list as I'm
progressing...)

In article ,
Sitsofe Wheeler wrote:
>On Mon, 2006-05-15 at 20:11 +0000, Andy Tanenbaum wrote:
>> We are looking at a VFS, but my initial inclination is not to
>> support files systems that are not "UNIX-like" due to the complexity.

>ast followed up with this:
>On Mon, 2006-05-15 at 21:35 +0000, Andy Tanenbaum wrote:
>> As to VFS, I am trying to avoid bloat. I think the only thing anyone actually
>> does with a CD is copy files from it (or burn files to it). I don't think
>> there is a lot of demand for mounting them, really, just a better way to read
>> them.
>
>This is fairly consistent with what asw was saying. It won't be done for
>bloat and complexity issues.

There is a good chance that (when done properly) the kind of VFS Andy
Tanenbaum is talking about will also allow filesystem implementations for
CD-ROMs, DOS, WinNT, etc. You do a lot of things without special hooks
in the VFS interface.


--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency