XML

kent logo

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.


Question 81:

Is it a requirement to implement the file-copy using buffers and transferring content of one file to another in chunks ? If we copy the content of one file to another all in one go, will we be penalised ?

Answer 81:

See the answer to Question 75 (2004).

Keywords: moss2004 , moss2004-1


Question 82:

For writing to the file, when opening it, can we use 3 flags such as "MFileOps.OPEN_WRITE", "MFileOps.OPEN_CREAT" and "MFileOps.OPEN_TRUNC" all in the same "MPosixIf.open()" call. Will it work ? Because I'm doing the same thing and it's not truncating the file before copying to it on both the host and object file system.

Answer 82:

This should work fine for the object file-system, even though specifying "MFileOps.OPEN_CREAT" and "MFileOps.OPEN_TRUNC" together doesn't make much sense. As suggested in Question 60 (2004), try putting in some debugging print statements to check the flags at a lower-level.

Keywords: moss2004 , moss2004-1


Question 83:

For the following method in MPosixIf:

    public static int access (String path, int amode)

What value would be passed for "amode" ? I know it is relating to the modes of a file or a directory but how can I pass them to the method in int form ?

Answer 83:

See the documentation for MPosixIf. The modes relate to constants in "MFileOps".

Keywords: moss2004


Question 84:

I've chosen to do the file copy option, I've been looking at it now for a good few days, but still don't know where to start. Have you got any suggestions ?

Answer 84:

The current set of anonymous questions and answers should provide a good indication of what is involved. You could start by modifying "UCopy.java" to process some simple arguments (e.g. "--help") and go from there.

Keywords: moss2004 , moss2004-1


Question 85:

Do we need to add new methods to the "UCopy" class ?

Answer 85:

That's up to you. But if you do add methods, make sure they're sensible (i.e. don't over complicate).

Keywords: moss2004 , moss2004-1

Referrers: Question 88 (2004)


Question 86:

Can you give any hints on how to create a file in the given directory ?

Answer 86:

I'd suggest having a look at the source code to "/bin/wfln" (in the file "moss/modules/UWfln.java"). This creates a file and writes some text to it.

Keywords: moss2004 , moss2004-1


Question 87:

You mentionned in Question 80 (2004) that:

"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);

How is this information useful ? How do we physically seek through an open file ?!

Answer 87:

This information is probably not useful for this assignment, perhaps, but would undoubtedly be useful for other purposes. You seek through an open file using "lseek()".. (or by starting at the front and reading until you get to the right location, but that's wasteful if you don't actually need the data).

Keywords: moss2004 , moss2004-1

Referrers: Question 96 (2004)


Question 88:

Following from Question 85 (2004), do you mean if we do not add new methods, that all the code we write should be in "main()" ?

Answer 88:

Yes -- where else would it go ?

Keywords: moss2004 , moss2004-1


Question 89:

I get the following error when calling the "open" method, but have no idea what it means:

    MProcFS.open(file_dest, mfile_handle, 0, 1);

non-static method open(java.lang.String,moss.fs.Mfile,int,int) cannot be referenced from a static context.

Answer 89:

The particular "open" method you're trying to call here belong to "MProcFS", i.e. the process file-system. The only thing that should call this "open()" is the code in "MFileSystem" (that is responsible for file-system stuffs -- e.g. redirecting open/etc. requests to the right file-system). The compiler error is saying that you can't call this particular "open()" as a static method -- because it's not static -- it needs an instance of the process file-system.

If you're just trying to open a file from an ordinary MOSS user-process, you should use "MPosixIf.open()". Generally speaking, MOSS user processes (i.e. things in the "moss/modules/" source tree) should only use methods in "MPosixIf" -- i.e. the interface to the operating-system.

Keywords: moss2004


Question 90:

Could we please have a list of suggested first steps for the file copy option, you see we are editing a massive program with loads of lines of irrelevant code, its hard to see the wood from the trees. Why do we need to edit such a large program anyway ? surely the same programming task could have been set without the window dressing of moss.

Answer 90:

The first steps for the file-copy utility would be something like:

then once both files are open, get copying the data between them.

You say you need to edit a large program, but you don't. You only need to deal with the code in "moss/modules/UCopy.java" (which is 74 lines in its default state). My "model" answer for this is 206 lines (only editing "UCopy.java"). The only other material you really need to look at is the documentation for MPosixIf. However, looking at the source code for something else that writes files (e.g. "moss/modules/UWfln.java") will provide some insight into the sort of code required.

The point of the "window dressing" is to give you some moderately real experience with operating-system programming; this is an operating systems course, after all. Just writing a Java program to copy files teaches you very little about the underlying OS and how user processes interact with it. The pedagogical justification is in the learning-outcomes for the assessment..

Keywords: moss2004 , moss2004-1


Question 91:

I can't get MOSS to do anything under BlueJ. If "MiniOSSim" is run the terminal refuses to terminate with the "exit" command, and if a "BlueMOSS" instance is created it doesn't let you type anything in! all the sections are compiled, and I don't have a clue how to do programming from a command line, can you give us a patch so MOSS works in BlueJ ?

Answer 91:

Unfortunately, MOSS won't ever run properly in BlueJ, although I've had varying degrees of success. Bear in mind that the version of BlueJ installed on the PPCs and by default on raptor is quite old. The latest version(s) of BlueJ should be more functional. But...

As recommended in the assignment, don't run MOSS from BlueJ -- use BlueJ to edit and compile the code by all means, but it's best run from raptor's command-line. As described in the assignment description all you need to is change into the UNIX directory where MOSS resides and type:


    bash$ java moss/MiniOSSim

which is exactly the same as what you'd get in the BlueJ Java-console.

As you say, typing "exit" at the MOSS prompt doesn't do anything -- almost expected. It will exit the "console" process, but the rest of MOSS is mostly free to keep on running -- note that termination is not a normal event for an operating-system (or at least it shouldn't be!). The way to kill MOSS is reset the JVM. From the MOSS home-page (section 4.3):

To shut-down MOSS, right-click the "barber's pole" and reset the virtual-machine.

The way to kill MOSS from a UNIX terminal is just to ctrl-C it (which works on most UNIX programs). The "BlueMOSS" class should work -- well, it works in BlueJ 2.0.2 Java 1.5.0...

Keywords: moss2004

Referrers: Question 95 (2004)


Question 92:

How do we run "/bin/wfln" ? I run it like:

    /bin/wfln README.TXT "Hello Everyone"

but I always get an error saying:

    /bin/wfln: failed to open README.TXT for writing: no such file or directory

Answer 92:

See the answers to Question 66 (2004) and Question 46 (2004) -- you must give an absolute path (e.g. "/README.TXT").

Keywords: moss2004

Referrers: Question 98 (2004) , Question 99 (2004)


Question 93:

If you wrote the MOSS program then I am sorry to say this Fred but your choice of variable names and commenting is really BAD. Poor commenting, you need lectures from Peter Welch, he knows how to comment well. But you did deduct marks for commenting in semaphores.

Answer 93:

I'll partially agree with you about commenting, but I think my variable-name choices are, on the whole, quite sensible. The worst example of commenting (rather, a lack of it) is arguably in some of the "moss/modules/" files -- some are commented properly, others are nearly devoid of comments (for which there is no excuse, really, except that it was probably late and I'd already written very similar code n times before..). Much of the rest of MOSS is commented properly, better in some places than others. But if there's some specific code in MOSS that you don't understand (e.g. due to a lack of comments), ask! (the course newsgroup or these anonymous pages are ideal).

Sometimes, however, and referring to your last point, people do tend to generate pointless comments. The main purpose of comments is to help programmers understand the code; if they don't aid in this task, they're probably redundant (with the obvious exceptions of things like boilerplates and Javadoc wrapping). But in cases where I have deducted marks for commenting, it's in an attempt to get you to comment your code better.

Keywords: moss2004


Question 94:

I have started implementing the unlink method, and think I have done the first point of the solution, but am having real trouble finding a place to start for the unlinking bit. Any help on this would be great.

Answer 94:

This is where it starts to get complicated, but not excessively so. Directories in the object file-system are held as "MObjFSDir" objects. To remove a file from a directory, you need to get hold of the directory object, then delete the file from within it. This last bit will probably involve adding a new method to "MObjFSDir".

Keywords: moss2004 , moss2004-2


Question 95:

When running MOSS from BlueJ, the exit command doesn't work, and in the "BlueMOSS" instance when used doesn't even let you type anything in, what am I doing wrong ? everything is compiled.

Answer 95:

See the answer to Question 91 (2004).

Keywords: moss2004


Question 96:

You said (in Question 87 (2004)):

You seek through an open file using "lseek()".. (or by starting at the front and reading until you get to the right location, but that's wasteful if you don't actually need the data).

Ok, I'm guessing we need some kind of loop but is there a method we can use that allows us to place text directly at a certain offset ? Thanks

Answer 96:

No, there isn't, but you could easily write one -- just an "lseek()" followed by a "write()". But this is not something you need, at least until it comes to appending existing files. Both "MPosixIf.read()" and "MPosixIf.write()" advance the file-pointer according to the amount of data read or written. So when simply copying one file to another, you just read() and write() -- the file-pointers are updated automatically. "lseek()" is needed to append a file, since you must seek to the end of it before you start writing -- but getting this to work is secondary to getting the basic copy working (since append operation depends on a command-line flag).

Keywords: moss2004 , moss2004-1


Question 97:

How do I run "moss/modules/Ucopy.java" so that it outputs "hello" both in BlueJ and UNIX, all that I can get at the moment is "MOSS# ".

Answer 97:

I assume you mean "moss/modules/UCopy.java" -- be case sensitive. That Java file, rather its corresponding class file, ends up as "/bin/copy" in MOSS. So, as shown in Question 78 (2004) (and various other similar examples), run it by typing "/bin/copy".

Keywords: moss2004 , moss2004-1


Question 98:

In continuation to Question 92 (2004), I now run "/bin/wfln" like:

    /bin/wfln /hello.TXT "Hello Everyone"

I get no error but "hello.txt" is not created in the MOSS folder - and even when I try it with a file currently there i.e. "/README.TXT" it doesn't work - also am I right in asuming that

    /bin/wfln /hello.TXT "Hello Everyone"

appends hello everyone to the file "hello.txt" ?

Answer 98:

My first point would be that you need to be a lot more aware of filename case. "hello.txt", "hello.TXT", "HELLO.TXT" and "Hello.txt" are all different files.. If you write to "/hello.TXT", then that'll create a file called "hello.TXT" in MOSS's root-directory. This is not visible on raptor or windows -- it's MOSS's file-system, no-one elses. See Question 78 (2004) for an example of how to display the contents of this file. Finally, no, "/bin/wfln" does not append to a file -- it'll just overwrite or create.

Keywords: moss2004 , moss2004-1

Referrers: Question 101 (2004)


Question 99:

When calling "open()", whether for reading or writing, I always get -2 returned from the method. Whether the file exists or not.

What am I doing wrong ? and how do we find out what these errors mean ? I've tried looking at the code for the "MPosixIf.open()" method and the relevant fs methods, but can't make sense of it.

    int fd_source = MPosixIf.open (file_source, MFileOps.OPEN_READ);

Answer 99:

The code -2 is "-MSystem.ENOENT". The full list of all error codes in in "moss/user/MSystem.java". If you want a human-readable string for an error-code, use "MStdLib.strerror" (as many of the existing programs already do). This code is presumably failing because you're not giving it a valid filename. Some other questions relate to this, e.g. Question 92 (2004) and Question 66 (2004).

Keywords: moss2004 , moss2004-1


Question 100:

My implementation has the optional arguments "-i" and "-a" following the file/direcory arguments. Is this ok ? as it's not exactly standard compared to the other MOSS commands.

Answer 100:

Strictly speaking, no, this is not ok. But you won't lose a huge amount of marks for doing this. The usage is specified in the default "UCopy.java" file as:

    /bin/copy [options] SOURCE DEST

so you should make sure your program behaves this way (with respect to command-line arguments).

Keywords: moss2004 , moss2004-1

Valid CSS!

Valid XHTML 1.0!

Maintained by Fred Barnes, last modified Thu May 8 12:58:04 2014