Master 512
Forum by Robin Burton
Beebug Vol. 9 No. 8 January / February 1991
I thought this month I'd deal with a number of points which, according to my mail, have caused a bit of trouble for quite a few of you from time to time.
FILE ATTRIBUTES
Most of us know what file attributes mean in the 512, but even so it appears that there are a few common misunderstandings for new users, particularly when they are carrying out certain operations.
File attributes in most operating systems share common ideas, but there are of course also differences. For example, in the Beeb's DFS a file can be locked or not, and that's it. In ADFS this idea is extended, so a file can be set to read only, write only, read and write or execute. In addition the first three can also have the lock attribute set too. (I've never quite been able to work out what use a locked write-only file is! Does anyone have any ideas?)
DOS too uses file attributes, again with similarities but also with differences of its own. Before I go on let me say that I know that most of these facts will be known to many of you, but as I've said before they're not all obvious to new users of the 512.
SYSTEM FILES
The first attribute which can cause some consternation is the 'system' attribute, because in DOS it makes a file invisible on the normal directory display and it also prevents it from being copied in the usual manner.
The problem for new 512 users is of course that there's nothing like it in BBC micro filing systems so it's a completely new idea. Strictly speaking, the system bit doesn't actually prevent files from being copied, so this is where the confusion arises.
The system attribute actually prevents any file with this bit set from being included in normal directory searches, hence a straightforward 'COPY' command for a file set to 'system' produces a simple 'file not found' instead of something more helpful.
One occasion when this can be particularly annoying is when you use wild cards in a copy command. DOS will copy all the normal files, omitting the system files, but it won't report anything amiss because there's no error. Only later might you realise that some of the files have been missed, particularly because they're not displayed normally anyway. Of course it's easy to avoid the problem by using a modifier with the copy command, so if you thought you had to set all the system files to 'DIR' before they could be copied (and perhaps set back to 'system' later on the new disc) you'll be pleased to know there's a much easier way.
If you want to copy all the system files from one disc to another, the copy command can have a '/S' modifier added onto the end, just like the directory command, so that, assuming drive A: is the current drive:
COPY *.* /S B:
will copy all the system files in the current directory to the current directory of drive B:, and there's no need to change the file attributes at all. However, bear in mind that this modified command will copy only system files, so you'll still need a normal 'COPY *.* B:' as well.
FSET
Another attribute which has frustrated some users is the read-only setting, shown as RO for short in DOS. There's nothing mysterious about it, it means exactly the same as 'locked' in DFS or ADFS. However, whereas these filing systems will helpfully report 'File locked' when you try to overwrite a locked file, DOS is less informative. DOS reports instead 'Access denied', which means exactly the same as 'File locked', but which is by no means as clear about the precise situation as it could be.
Suffice it to say that if you get the 'Access denied' message it always means that you're trying to modify a file (or disc) which is set to read only; there is no other cause. There's only one course of action to take and that is to set the target file to read-write. This sounds simple enough, but it has caused a bit of hair-pulling for a few users. 'FSET.CMD' is the utility you need and it's quite simple to use so long as you are aware of its peculiarities.
I have to admit that until a few months ago I hadn't thought about one of FSET's oddities. It had never bothered me simply because of the way my system is set up, so perhaps quite a number of you are in the same situation without knowing it. I always have FSET in a current PATH setting, so it can always be called from any directory on any drive in my system, and normally it's within the current working directory that I wish to amend file attributes.
However, if this isn't the case FSET simply will not work. Suppose you're in a directory called 'SPRDSHT' and you want to copy your updated masterpieces to a directory called 'SHEETBAK', but all the files in the backup directory are set to read-only. Obviously they must be set to read-write before the copy can take place. You'll find however, that in this situation you cannot enter, for example:
FSET B:SHEETBAK\*.* [RW]
COPY *.* SHEETBAK
FSET B:SHEETBAK\*.* [RO]
because FSET doesn't allow directory names to be included in a file specification. This looks like a bug, but it's not. It's caused by the fact that CMD files, (including FSET.CMD) are CP/M utilities, and CP/M simply does not have subdirectories. The problem for DOS Plus users is that the program wasn't updated for DOS use and it still doesn't understand directories, so you can only run it on files in the current directory. To carry out the above operation, therefore, the commands needed are actually:
B:
CD \SHEETBAK
FSET *.* [RW]
COPY A:SPRDSHT\*.*
FSET *.* [RO]
A:
assuming that you want to finish up in the original directory on the original drive, hardly convenient! Unfortunately this time there's no simple solution, you must just be aware of and allow for FSET's limited intelligence.
While we're looking at FSET there's one more point of which I've realised many people are not aware. Given FSET's limitations anything that makes life a bit easier is welcome, so I hope this saves one or two of you a bit of typing from time to time.
FSET can be used to change a file to read-only from read-write (or vice-versa) or from system to directory and back. The read-only attribute can be set on a file along with the system attribute at the same time, so when you want to copy such files to a different disc which already contains old versions of the same files with these attributes set you might think that you have two attributes to alter before starting the copy.
I heard from a member a while back about this very subject, and it was obvious from his letter that to perform this sort of operation he was issuing two separate FSET commands, when one can be used. To set a read-only-system file to read-write and directory the two changes can be specified together in one command, so using COMMAND.COM as an example the entry would be:
FSET COMMAND.COM [RW/DIR]
or changing it back again:
FSET COMMAND.COM [RO/SYS]
There's no need to issue separate commands for two changes, just separate the attributes by a '/' and FSET will apply them both in the one operation.
One more point frequently not realised is that 'SYS' and 'RO' do not need to be set together, nor do 'DIR and 'RW'. It's quite possible to have a 'RO/DIR' or a 'RW/SYS' file. Use 'SDIR' if you want to see all the different types of file attributes used in any directory.
By the way, have you noticed that you can miss off the trailing bracket from FSET commands? It seems that, having found a valid set of parameters preceded by a left square bracket FSET isn't bothered whether a right square bracket or a RETURN follows.
MOVE
MOVE.EXE is another command which seems to cause more than its fair share of problems for some people. The command is actually quite simple if you understand it, though it must be acknowledged that it can require a pretty lengthy command line at times.
From what I hear of users' problems with MOVE it seems again that several particular problems crop up more often than others. The first of these we've indirectly covered, that is that no matter which filing systems are involved and in which direction the transfer is to be, the target files must not be locked or read-only. That's pretty obvious, but it's also very easy to overlook, it seems.
The second most common difficulty is also self-inflicted, but this time there's more of an excuse. From my experiences it appears that some of you try to make the command more complicated than it needs to be, and not surprisingly you get problems.
For illustration let's suppose that you want to transfer a DFS file called 'LETTER' to DOS so you can import it into a DOS text file. The first point is that MOVE.EXE itself must be available in a current path. Again this is simple enough, but I frequently hear of users trying to copy files from DFS or ADFS drive :0 when the currently selected DOS drive is A: (think about it!)
While I remember it I'll mention another situation which has foxed a few. A problem for floppy disc only systems is copies between DFS and ADFS, when of course there isn't a 'spare' drive for DOS. Well actually there is, but you need to set up a RAM disc in this case, then select that as your current DOS drive, ensuring that both MOVE.EXE and COMMAND.COM have been copied to it. You can then use both floppy drives for BBC micro filing system transfers with no trouble.
Back to the unnecessary complexities. By far the most frequent is that users include the root directory in a file specification. MOVE frequently doesn't like it!
OK, this is less obvious, but with a bit of thought it's clear that in DFS, ADFS or DOS everything is subordinate to the root directory, whether it's a file or another directory. Once you've accepted that point it's obvious that there's no need to specify the root directory in the command unless it is the only parameter.
Remember in MOVE the source specification can be either a list or a file, so if you MOVE a list of files from the root or the current directory, only the file list spec. is needed, '*' or as appropriate.
Using our example file, to copy it to the current directory of drive A: in DOS the source disc must obviously be drive :1 (or perhaps :3 for DFS), so assuming that the file is in the root directory of the BBC ADFS disc, the command would be:
MOVE :1.LETTER -ADFS A: -DOS
or, even shorter:
MOVE :1.LETTER -ADFS . -DOS
so the command can be extremely simple (if you're not familiar with the use of the '.' in the above command look back over the last few Forums for an explanation). If we had a list of files called 'LETTER1', 'LETTER2' and so on the command simply changes to:
MOVE :1.LETTER* -ADFS . -DOS
If there is a need to supply a directory path in either part of the command just specify it in the usual way for the filing system concerned, for example:
MOVE :1.LETTER -ADFS \DOCS -DOS
will move all the 'LETTER' files to directory 'DOCS' on the current DOS drive, instead of using the current directory. Likewise:
MOVE :1.TEXT.LETTER -ADFS A: -DOS
would move all the 'LETTER' files from directory 'TEXT' of ADFS drive 1 to our current DOS directory in drive A:. There's one other item which I must mention, since it has tripped up a surprisingly large number of people, and that is the filing system should always be specified in both the source and the target portion of the command, there are no defaults.
The final problem I'll mention with MOVE is really trivial, but it is certainly one of the most frequent mistakes I hear about. Please note, the filing system identifier for transfers to or from DFS is '-DISC'. It is NOT '-DFS'!