440
Platforms
©2000-2008 Tibbo Technology Inc.
R/O property will read 1- YES.
During mounting, the fd. object accesses the
of the disk, read the
size of all disk areas, and determines if the flash disk is healthy. This does not
include detailed checks of each file or data sector of the disk, but is enough to
"catch" gross problems, such as disk corruption due to an increase in the
application size.
Once the disk has been mounted, you can
, and perform other disk-related operations.
There is no way to explicitly dismount the disk, nor it is necessary. The disk will be
dismounted automatically if any fatal condition is detected when working with it.
This condition will be reflected by the
R/O property, while the
will become 0- NO. Not every error indicated by the fd.laststatus is
fatal (see
topic).The disk will also be dismounted if
or uses
to write to a sector
belonging to a mounted flash disk.
File Names and Attributes
Every file you create on the flash disk has a file name and attributes. Both share a
single text string that can be up to 56 characters long. The attributes (if any) are
separated from the file name by a space. In other words, everything up to the first
space is the file name, and everything else -- attributes.
The file names are case-sensitive and can include any characters, except,
obviously, the space. This includes "/" and "\". The flash disk does not support
subdirectories, but it is possible to emulate them by including "/" or "\" characters
in the file name. The "." character can be used to, so you can have any extension
(s) you like. The attributes portion of the string may contain any characters
whatsoever.
It is quite common for file systems to define attributes for the files. Typically,
however, these attributes are preset. That is, you have a fixed list of things you
can define about the file, such as the creating time, read-only flag, etc.
The fd. object uses a different approach. In a system that only runs a single
application at any given time, it makes no sense to have, say, a fixed read-only
flag. There is only one application running, after all. This application probably
knows what files not to touch anyway! Our how about the date and time of the file
creation? Does it make sense to keep this on a system without a real-time clock?
Quite obviously, no.
For the above reasons, the fd. object allows you to store any attribute data and
interpret it in any way you want. There is an attribute string and you can fill it with
any data of your choosing and in accordance with the needs of your application.
And yes, you can implement the read-only flag and record the creation date and
time -- but only if you need to.
and set its attributes too:
...
fd.create("File1.dat R 25-JUL-2008")
' <File1.dat> is the file name, <R
25-JUL-2008> -- attributes, it is up to our program how to interpret this!
476
437
441
441
472
476
435
467
483
441