|
CO527 Anonymous Questions and Answers |
This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
What is the fastest way of finding whether a file exists on the system?
Probably to "MPosixIf.stat()" it.
Keywords: moss2004
You said (in Question 60 (2004)) that the host file-system does not support "OPEN_TRUNC". For which system is the copy utility implemented for then ?
The copy utility isn't implemented for anything here; that's something you have to do. If you mean, what file-systems is "OPEN_TRUNC" supported/implemented on, then the answer is just the object file-system (that is mounted at the root).
Keywords: moss2004 , moss2004-1
Referrers: Question 79 (2004)
Where are the notes for "Part L - Multiprocessing" ?
I mentioned this in the lecture; they're part of the "miscellaneous system topics" notes.
I can't seem to get MOSS to run on raptor, I've un-tar'd it, run make. That all seems to work fine but when I try to run the Java class file I get an error:
raptor$ java moss/MiniOSSim
Exception in thread "main" java.lang.NoClassDefFoundError: MiniOSSim.
Any help you could offer would be appreciated.
Did you run "make" in the right place ? The error is presumably because "moss/MiniOSSim.class" doesn't exist; more importantly, if you look in the "moss/" sub-directory there should be some more directories and a "MiniOSSim.java". You should run "make" (and the simulator) from within the "moss/" directory extracted from the archive.
Keywords: moss2004
Hi, I am using the following code to truncate a file, and create one if it does not exist:
[snip code]
However, when run I keep getting an I/O error. Where am I going wrong ?
Posting large slabs of code isn't generally recommended; it makes the answer less general. The likely reason for an I/O error is because you can't perform the operation you're trying to. From the code, this probably means you can't write to the file you're specifying as a destination. The object file-system does not return EIO for anything except "fcntl()" calls. Trying to write (or create) files in the process or device file-systems will likely result in such errors. Try writing to something like "/foo" -- that should always work.
Keywords: moss2004 , moss2004-1
Using the code:
int fd = MPosixIf.open ("os.txt", MFileOps.OPEN_READ);
Where would it be reading the file "os.txt" from ? Is that in the MOSS directory, or do we need to give the whole file address such as "/home/cut/abc123/c0501/moss" etc. ? Neither way seems to work.
As mentioned in Question 46 (2004), MOSS processes have no concept of a working directory, so any filename given must be absolute. The reason your "/home/cut/abc123/..." path won't work is because it doesn't exist in MOSS's file-system -- that path refers to something on raptor's file-system. However, raptor's file-system is mounted in MOSS by means of the "host file-system" at "/host", so such a file would be visible from MOSS as "/host/home/cut/abc123/co501/moss/...". But for this, I'd recommend only writing to files in MOSS's "object file-system", mounted at the root "/". Exploring the MOSS filesystem as described here should provide some insight into what MOSS's file-system looks like.
Keywords: moss2004 , moss2004-1
Referrers: Question 92 (2004) , Question 99 (2004)
In "MHostFS.java" what method am I editing to implement truncation ? I have found "unlink()" and "mkdir()" but not anything that looks like truncate.
In the assignment description:
which implies something in "open()".
Keywords: moss2004 , moss2004-4
I am a little confused as to how the main copy process takes place. At the moment I can reference the file using "MPosixIf.open()". I assume we then use the read and write methods - but these seem to only output ints. How would the actual data stream of a file be accessed so it can be placed into a new file ?
Looking at the documentation for MPosixIf should provide the answer to this. You use the integer returned from "MPosixIf.open()" (i.e. the file-descriptor) as a parameter to the read/write methods, along with a buffer and a count -- i.e. the data goes in and out via the "buffer" parameter (an array of "byte"s).
Keywords: moss2004 , moss2004-1
If we want to truncate the file using "MFileOps.OPEN_TRUNC" can we assume that this works even though it hasn't been implemented ?!
It has been implemented (see Question 60 (2004)), for the object file-system at least, that should be more than adequate for testing.
Keywords: moss2004 , moss2004-1
What does it mean by: integer file decriptor as returned by MPosixIf.open() ?
File-descriptors are what MOSS processes use to refer to open files (that might be files, directories, pipes, sockets, etc.); and these descriptors are simple integers. Thus, when you perform some operation on an open file, you use the file-descriptor. In this case file reads and writes.
Underneath the user-level in MOSS, i.e. in its kernel, these integer descriptors are mapped onto actual file-handle objects -- on a per-process basis (see the fields in "MProcess.java"). You can look at the implementation of "MPosixIf.open()", "MPosixIf.read()", etc. to see how these fit together.
Keywords: moss2004 , moss2004-1
Once we have determined that the target given is a directory and not a file, how do we then create a new file in this directory of the same name as the source file ? The "MPosixIf.opendir()" method does not allow any flags... so I assume once it is opened you can just write straight to it, but doesn't the file-descriptor need to relate to the complete path of the file, not just the directory ?
Is one way of doing this to extract the filename from the source path, add this onto the target directory path and then open this for writing ? Or am I looking at this completely the wrong way ?
You are correct in your thinking there -- yes, if the target is just a directory name, you need to extract the file-name from the source, add it to the target path and then open that for writing. Once you've got a directory open (from "MPosixIf.opendir()") you can only read directory entries from it (with "MPosixIf.readdir()"); you'll get an error if you try to use "MPosixIf.read()" or "MPosixIf.write()" with it.
Keywords: moss2004 , moss2004-1
Hey, I'm doing the file copy utility and I'm a little stuck on a couple of things.
I'm a little worried that I'm going off in completely the wrong direction with my code. So far I have:
...
System.out.println ("file exists, overwrite? [Y/N]");
try{
InputStreamReader isr = new InputStreamReader (System.in);
BufferedReader br = new BufferedReader (isr);
String s = br.readLine();
...
} catch (IOException e) {
...
}
...
on how to read input from the user in MOSS. Basically if you see the above, I'm trying to implement a "File exists, overwrite?" prompt. Obviously the user needs to specify Y or N. I've been trying to do this with buffered readers and writers on "System.in" with no success.
Any tips ?
As you've discovered, this doesn't work. But, consider what would happen if I logged into MOSS over the network (e.g. with telnet) and ran code like the above: the prompt would end up on the console of MOSS, not on my terminal.
The correct way to interact for MOSS processes to interact with the user is via their own standard input and output streams. The default "UCopy.java" has this in it:
MPosixIf.writestring (MPosixIf.STDOUT, "hello world from " + argv[0] + "! :)\n");
that just writes that message to the user's terminal (the MOSS console in most cases).
To read input from the user, you need to use "MPosixIf.read()" on the "MPosixIf.STDIN" file-descriptor. "MPosixIf.STDIN", "MPosixIf.STDOUT" and "MPosixIf.STDERR" are just integer constants (0, 1 and 2 respectively).
Like reads and writes on files, reads from "MPosixIf.STDIN" and writes to "MPosixIf.STDOUT" map onto lower-level operations in MOSS. If you're running programs through the MOSS console, these operations will ultimately end up as reads and writes from Java's "System.in" and "System.out" streams (i.e. the Java console). The code that actually does this (for the MOSS/Java console) is in "drivers/MJavaConsole.java", that you're free to examine (but not modify!). The reason reads from "System.in" don't work in your process is because there's a thread in "MJavaConsole" that's already reading from "System.in".
Keywords: moss2004 , moss2004-1
Referrers: Question 104 (2004) , Question 121 (2004) , Question 123 (2004)
Are you going to be putting that diagram online as well as the slides ?
I've made a slightly nicer version (not hand-drawn) and put that online. Available from the course handouts page.
Can you explain what does the flags such as "MFileOps.OPEN_TRUNC" and others do ? I really can't get my head around as to how we are going to use them in creating the file-copy utility.
A list of available flags ("OPEN_..." in this case) and descriptions of them can be found in the MFileOps documentation. You need to specify at least one of these flags, possibly more, when opening files with "MPosixIf.open()" (combined with a bitwise "or").
Keywords: moss2004 , moss2004-1
ok, with copying:
int MPosixIf.read (int fd, byte[] buffer, int count)
int MPosixIf.write (int fd, byte[] buffer, int count)
I need two file descriptors, one to read from and one to write to. Thats easy enough, where I am confused is with the buffer array, and the count.
How do we know how large to make these ? Is there a way of querying the size of a file ? That way the whole file gets buffered, but on a big file isn't that a complete waste of space ? So an obvious problem is to make the buffer small I suppose and loop over until the whole file has been read from and written to in chunks. But then in the loop won't the read process keep reading the same bit of the file over and over ?
Yes, there is a way to query the size of a file, using "MPosixIf.stat()", but this is not something that you want to do for the purpose of obtaining a buffer size. As you say, it'll be a complete waste of memory for large files (what if I wanted to copy a 16 gigabyte file ? -- just can't allocate that sort of space!). So, you need to pick a suitable buffer size and do the copy in chunks. The "count" parameter specifies how much you'd like to read or write from "buffer", but isn't necessarily the amount that actually gets read or written -- that's returned by these methods (or 0 for end-of-file and -1 on error), as described in the documentation. Repeated reads from (or writes to) an open file automatically advance the "file-pointer" associated with the file (e.g. if you look at the fields in "MFile.java", that provides the in-kernel file-handle). You wouldn't read the same bit over and over unless you explicitly re-wound the file-pointer back to the beginning of the file.
Keywords: moss2004 , moss2004-1
Referrers: Question 81 (2004)
You said we can use "MPosixIf.stat()" to query the size of the file. But this method returns 0 on success (according to the documentation) which obviously is not the file size. What exactly is the purpose of "MPosixIf.stat()" and how can we get the size of a file ?
The purpose of "MPosixIf.stat()" is to "stat" files (i.e. return status information about the file). The interface is defined as:
static int stat (String path, MInode statbuf)
Information about the file (assuming success) is placed in the "MInode" specified by "statbuf". The file-size is retrievable from the "size" field of "statbuf".
Keywords: moss2004 , moss2004-1
How are we supposed to "append" to a file ?
This was my bug, apologies for that.
There is a missing "lseek()" method in MPosixIf that's needed to seek to the end of a file (so it can be appended). To fix this, copy this file from raptor:
/usr/local/courses/co501/frmb/assess3/MPosixIf-lseek.java
and place its contents somewhere suitable in "moss/user/MPosixIf.java". Or just replace the whole of MPosixIf.java (if you've not edited it) with this file:
/usr/local/courses/co501/frmb/assess3/MPosixIf.java
Documentation on lseek() is in that Java fragment, or see the very similar lseek() method for MFileOps (except that MPosixIf's lseek() has an integer as its first argument, not an MFile).
Keywords: moss2004 , moss2004-1
Referrers: Question 140 (2004) , Question 143 (2004) , Question 144 (2004)
What is the best way to test the copy utility as truncate is not implemented for the host file-system ?
Just test it on the object file-system instead! E.g.:
MOSS# /bin/copy /proc/cpuinfo /foo
MOSS# ll /
...
-rw-r--r-- 88 44 foo
MOSS# cat /foo
CPU0(busy): VCPU:JVM/1.4.2_06-b03/SunOS/5.9
CPU1(idle): VCPU:JVM/1.4.2_06-b03/SunOS/5.9
MOSS#
Keywords: moss2004 , moss2004-1
Referrers: Question 97 (2004) , Question 98 (2004) , Question 112 (2004)
How can we make sure that the file is completely empty to which we are copying to ? I know it would be using "MFileOps.OPEN_TRUNC" but will that be specified in the "open()" method ? I did that and and it didn't work as the destination file still has some of the old content left after the content from the source file was copied.
Yes, specifying "MFileOps.OPEN_TRUNC" in the flags to "MPosixIf.open()" should cause the file to be truncated. However, as mentioned in Question 60 (2004) and Question 62 (2004), truncate is only supported on the object file-system. But, once truncated, there won't be any old content left in the destination file.
Keywords: moss2004 , moss2004-1
I am confused on how to use the "lseek()" method. With something like:
offset = MPosixIf.lseek (fd, 0, MFileOps.LSEEK_END);
Where can I use this "offset" value ? The "MPosixIf.write()" method does not allow me to use the offset ? Do I need to combine it with the descriptor in some way ?
The returned offset is for information only. This allows a program to find out the current offset within a file, e.g.:
int cur_offset = MPosixIf.lseek (fd, 0, MFileOps.LSEEK_CUR);
Keywords: moss2004 , moss2004-1
Referrers: Question 87 (2004)
|
Maintained by Fred Barnes, last modified Thu May 8 12:58:04 2014 |
