OpenCores
URL https://opencores.org/ocsvn/or1k_old/or1k_old/trunk

Subversion Repositories or1k_old

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /or1k_old/trunk/rc203soc/sw/uClinux/Documentation/filesystems
    from Rev 1765 to Rev 1782
    ↔ Reverse comparison
  •

Rev 1765 → Rev 1782

/isofs.txt
0,0 → 1,31
Mount options that are the same as for msdos partitions.
 
uid=nnn All files in the partition will be owned by user id nnn.
gid=nnn All files in the partition will be in group nnn.
umask=nnn The permission mask (see umask(1)) for the partition.
conv=binary Data is returned exactly as is, with CRLF's. [default]
conv=text (Carriage return, line feed) is replaced with newline.
conv=mtext (Carriage return, line feed) is returned as is (?).
conv=auto Chooses, file by file, conv=binary or conv=text (by guessing)
 
Mount options that are the same as vfat partitions. These are only useful
when using discs encoded using Microsoft's Joliet extensions.
iocharset=name Character set to use for converting from Unicode to
ASCII. Joliet filenames are stored in Unicode format, but
Unix for the most part doesn't know how to deal with Unicode.
There is also an option of doing UTF8 translations with the
utf8 option.
utf8 Encode Unicode names in UTF8 format. Default is no.
 
Mount options that are unique to the isofs filesystem.
nojoliet Ignore Joliet extensions if they are present.
norock Ignore rockridge extensions if they are present.
unhide Show hidden files (?).
cruft Handle badly formatted CDs (?)
map=off Do not map non-rockridge filenames to lowercase
map=normal Map rockridge filenames to lowercase
check=relaxed
check=strict
block=512 Set the block size for the disk to 512 bytes
block=1024 Set the block size for the disk to 1024 bytes
block=2048 Set the block size for the disk to 2048 bytes
/00-INDEX
0,0 → 1,20
00-INDEX
- this file (info on some of the filesystems supported by linux).
affs.txt
- info and mount options for the Amiga Fast File System.
hpfs.txt
- info and mount options for the OS/2 HPFS.
isofs.txt
- info and mount options for the ISO9660 (CDROM) filesystem.
ncpfs.txt
- info on Novell Netware(tm) filesystem using NCP protocol.
romfs.txt
- Description of the ROMFS filesystem.
smbfs.txt
- info on using filesystems with the SMB protocol (Win 3.11, Win NT)
sysv-fs.txt
- info on the SystemV/Coherent filesystem.
umsdos.txt
- info on the umsdos extensions to the msdos filesystem.
vfat.txt
- info on using the VFAT filesystem used in Win NT and Win 95
/romfs.txt
0,0 → 1,188
 
ROMFS - ROM FILE SYSTEM
 
This is a quite dumb, read only filesystem, mainly for initial ram
disks of installation disks. It has grown up by the need of having
modules linked at boot time. Using this filesystem, you get a very
similar feature, and even the possibility of a small kernel, with a
file system which doesn't take up useful memory from the router
functions in the basement of your office.
 
For comparison, both the older minix and xiafs (the latter is now
defunct) filesystems, compiled as module need more than 20000 bytes,
while romfs is less than a page, about 4000 bytes (assuming i586
code). Under the same conditions, the msdos filesystem would need
about 30K (and does not support device nodes or symlinks), while the
nfs module with nfsroot is about 57K. Furthermore, as a bit unfair
comparison, an actual rescue disk used up 3202 blocks with ext2, while
with romfs, it needed 3079 blocks.
 
To create such a file system, you'll need a user program named
genromfs. It is available via anonymous ftp on sunsite.unc.edu and
its mirrors, in the /pub/Linux/system/recovery/ directory.
 
As the name suggests, romfs could be also used (space-efficiently) on
various read-only medias, like (E)EPROM disks if someone will have the
motivation.. :)
 
However, the main purpose of romfs is to have a very small kernel,
which has only this filesystem linked in, and then can load any module
later, with the current module utilities. It can also be used to run
some program to decide if you need SCSI devices, and even IDE or
floppy drives can be loaded later if you use the "initrd" -- initial
ram disk -- feature of the kernel. This would not be really news
flash, but with romfs, you can even spare off your ext2 or minix or
maybe even affs filesystem until you really know that you need it.
 
For example, a distribution boot disk can contain only the cd disk
drivers (and possibly the SCSI drivers), and the ISO filesystem
module. The kernel can be small enough, since it doesn't have other
filesystems, like the quite large ext2fs module, which can then be
loaded off the CD at a later stage of the installation. Another use
would be for a recovery disk, when you are reinstalling a workstation
from the network, and you will have all the tools/modules available
from a nearby server, so you don't want to carry two disks for this
purpose, just because it won't fit into ext2.
 
romfs operates on block devices as you can expect, and the underlying
structure is very simple. Every accessible structure begins on 16
byte boundaries for fast access. The minimum space a file will take
is 32 bytes (this is an empty file, with a less than 16 character
name). The maximum overhead for any non-empty file is the header, and
the 16 byte padding for the name and the contents, also 16+14+15 = 45
bytes. This is quite rare however, since most file names are longer
than 3 bytes, and shorter than 15 bytes.
 
The layout of the filesystem is the following:
 
offset content
 
+---+---+---+---+
0 | - | r | o | m | \
+---+---+---+---+ The ASCII representation of those bytes
4 | 1 | f | s | - | / (i.e. "-rom1fs-")
+---+---+---+---+
8 | full size | The number of accessible bytes in this fs.
+---+---+---+---+
12 | checksum | The checksum of the FIRST 512 BYTES.
+---+---+---+---+
16 | volume name | The zero terminated name of the volume,
: : padded to 16 byte boundary.
+---+---+---+---+
xx | file |
: headers :
 
Every multi byte value (32 bit words, I'll use the longwords term from
now on) must be in big endian order.
 
The first eight bytes identify the filesystem, even for the casual
inspector. After that, in the 3rd longword, it contains the number of
bytes accessible from the start of this filesystem. The 4th longword
is the checksum of the first 512 bytes (or the number of bytes
accessible, whichever is smallest). The applied algorithm is the same
as in the AFFS filesystem, namely a simple sum of the longwords
(assuming bigendian quantities again). For details, please consult
the source. This algorithm was chosen because although it's not quite
reliable, it does not require any tables, and it is very simple.
 
The following bytes are now part of the file system; each file header
must begin on a 16 byte boundary.
 
offset content
 
+---+---+---+---+
0 | next filehdr|X| The offset of the next file header
+---+---+---+---+ (zero if no more files)
4 | spec.info | Info for directories/hard links/devices
+---+---+---+---+
8 | size | The size of this file in bytes
+---+---+---+---+
12 | checksum | Covering the meta data, including the file
+---+---+---+---+ name, and padding
16 | file name | The zero terminated name of the file,
: : padded to 16 byte boundary
+---+---+---+---+
xx | file data |
: :
 
Since the file headers begin always at a 16 byte boundary, the lowest
4 bits would be always zero in the next filehdr pointer. These four
bits are used for the mode information. Bits 0..2 specify the type of
the file; while bit 4 shows if the file is executable or not. The
permissions are assumed to be world readable, if this bit is not set,
and world executable if it is; except the character and block devices,
they are never accessible for other than owner. The owner of every
file is user and group 0, this should never be a problem for the
intended use. The mapping of the 8 possible values to file types is
the following:
 
mapping spec.info means
0 hard link link destination [file header]
1 directory first file's header
2 regular file unused, must be zero [MBZ]
3 symbolic link unused, MBZ (file data is the link content)
4 block device 16/16 bits major/minor number
5 char device - " -
6 socket unused, MBZ
7 fifo unused, MBZ
 
Note that hard links are specifically marked in this filesystem, but
they will behave as you can expect (i.e. share the inode number).
Note also that it is your responsibility to not create hard link
loops, and creating all the . and .. links for directories. This is
normally done correctly by the genromfs program. Please refrain from
using the executable bits for special purposes on the socket and fifo
special files, they may have other uses in the future. Additionally,
please remember that only regular files, and symlinks are supposed to
have a nonzero size field; they contain the number of bytes available
directly after the (padded) file name.
 
Another thing to note is that romfs works on file headers and data
aligned to 16 byte boundaries, but most hardware devices and the block
device drivers are unable to cope with smaller than block-sized data.
To overcome this limitation, the whole size of the file system must be
padded to an 1024 byte boundary.
 
If you have any problems or suggestions concerning this file system,
please contact me. However, think twice before wanting me to add
features and code, because the primary and most important advantage of
this file system is the small code. On the other hand, don't be
alarmed, I'm not getting that much romfs related mail. Now I can
understand why Avery wrote poems in the arcnet docs to get some more
feedback. :)
 
romfs has also a mailing list, and to date, it hasn't received any
traffic, so you are welcome to join it to discuss your ideas. :)
 
It's run by ezmlm, so you can subscribe to it by sending a message
to romfs-subscribe@shadow.banki.hu, the content is irrelevant.
 
Pending issues:
 
- Permissions and owner information are pretty essential features of a
Un*x like system, but romfs does not provide the full possibilities.
I have never found this limiting, but others might.
 
- The file system is read only, so it can be very small, but in case
one would want to write _anything_ to a file system, he still needs
a writable file system, thus negating the size advantages. Possible
solutions: implement write access as a compile-time option, or a new,
similarly small writable filesystem for ram disks.
 
- Since the files are only required to have alignment on a 16 byte
boundary, it is currently possibly suboptimal to read or execute files
from the filesystem. It might be resolved by reordering file data to
have most of it (i.e. except the start and the end) laying at "natural"
boundaries, thus it would be possible to directly map a big portion of
the file contents to the mm subsystem.
 
- Compression might be an useful feature, but memory is quite a
limiting factor in my eyes.
 
- Where it is used?
 
- Does it work on other architectures than intel and motorola?
 
 
Have fun,
Janos Farkas <chexum@shadow.banki.hu>
/ncpfs.txt
0,0 → 1,12
ncpfs is a filesystem which understands the NCP protocol, designed by the
Novell Corporation for their NetWare(tm) product. NCP is functionally
similar to the NFS used in the tcp/ip community.
To mount a Netware-Filesystem, you need a special mount program, which
can be found in ncpfs package. Homesite for ncpfs is
ftp.gwdg.de/pub/linux/misc/ncpfs, but sunsite and its many mirrors
will have it as well.
 
Related products are linware and mars_nwe, which will give Linux partial
NetWare Server functionality.
Linware's home site is: klokan.sh.cvut.cz/pub/linux/linware,
Mars_nwe can be found on ftp.gwdg.de/pub/linux/misc/ncpfs.
/smbfs.txt
0,0 → 1,13
smbfs is a filesystem which understands the SMB protocol. This is the
protocol Windows for Workgroups, Windows NT or Lan Manager use to talk
to each other. smbfs was inspired by samba, the program written by
Andrew Tridgell that turns any unix host into a file server for DOS or
Windows clients. See ftp://nimbus.anu.edu.au/pub/tridge/samba/ for
this interesting program suite and lots of more information on SMB and
NetBIOS over TCP/IP. There you also find explanation for concepts like
netbios name or share.
 
To use smbfs, you need a special mount program, which can be found in
the ksmbfs package, found on
sunsite.unc.edu:/pub/Linux/system/Filesystems/smbfs.
 
/sysv-fs.txt
0,0 → 1,37
This is the implementation of the SystemV/Coherent filesystem for Linux.
It implements all of
- Xenix FS,
- SystemV/386 FS,
- Coherent FS.
 
This is version beta 4.
 
To install:
* Answer the 'System V and Coherent filesystem support' question with 'y'
when configuring the kernel.
* To mount a disk or a partition, use
mount [-r] -t sysv device mountpoint
The file system type names
-t sysv
-t xenix
-t coherent
may be used interchangeably, but the last two will eventually disappear.
 
Bugs in the present implementation:
- Coherent FS:
- The "free list interleave" n:m is currently ignored.
- Only file systems with no filesystem name and no pack name are recognized.
(See Coherent "man mkfs" for a description of these features.)
- SystemV Release 2 FS:
The superblock is only searched in the blocks 9, 15, 18, which corresponds to the
beginning of track 1 on floppy disks. No support for this FS on hard disk yet.
 
 
Please report any bugs and suggestions to
Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de> or
Pascal Haible <haible@izfm.uni-stuttgart.de> .
 
 
Bruno Haible
<haible@ma2s2.mathematik.uni-karlsruhe.de>
 
/umsdos.txt
0,0 → 1,96
Very short explanation for the impatient!!!
 
Umsdos is a file system driver that run on top the MSDOS fs driver.
It is written by Jacques Gelinas (jacques@solucorp.qc.ca)
 
Umsdos is not a file system per se, but a twist to make a boring
one into a useful one.
 
It gives you:
 
long file name
Permissions and owner
Links
Special files (devices, pipe...)
All is need to be a linux root fs.
 
There is plenty of documentation on it in the source. A formated document
made from those comments is available from
sunsite.unc.edu:/pub/Linux/system/Filesystems/umsdos.
 
Mostly...
 
You mount a DOS partition like this
 
mount -t umsdos /dev/hda3 /mnt
^
---------|
 
All option are passed to the msdos drivers. Option like uid,gid etc are
given to msdos.
 
The default behavior of Umsdos is to do the same thing as the msdos driver
mostly passing commands to it without much processing. Again, this is
the default. After doing the mount on a DOS partition, nothing special
happen. This is why all mount options are passed to the Msdos fs driver.
 
Umsdos use a special DOS file --linux-.--- to store the information
which can't be handle by the normal MsDOS file system. This is the trick.
 
--linux-.--- is optional. There is one per directory.
 
**** If --linux-.--- is missing, then Umsdos process the directory the
same way the msdos driver do. Short file name, no goodies, default
owner and permissions. So each directory may have or not this
--linux-.---
 
Now, how to get those --linux-.---.
 
\begin joke_section
 
Well send me a directory content
and I will send you one customised for you.
$5 per directory. Add any applicable taxes.
\end joke_section
 
A utility umssync creates those. The kernel maintain them. It is available
from the same directory above (sunsite) in the file umsdos_progs-0.7.tar.gz.
A compiled version is available in umsdos_progs-0.7.bin.tar.gz.
 
So in our example, after mounting mnt, we do
 
umssync .
 
This will promote this directory (a recursive option is available) to full
umsdos capabilities (long name ...). A ls -l before and after won't show
much difference however. The file which were there are still there. But now
you can do all this:
 
chmod 644 *
chown you.your_groupe *
ls >THIS_IS.A.VERY.LONG.NAME
ln -s toto tata
ls -l
 
Once a directory is promoted, all subdirectory created will inherit that
promotion.
 
What happen if you boot DOS and create files in those promoted directories ?
Umsdos won't notice new files, but will signal removed file (it won't crash).
Using umssync in /etc/rc will make sure the DOS directory is in sync with
the --linux-.---.
 
It is a good idea to put the following command in your RC file just
after the "mount -a":
 
mount -a
/sbin/umssync -i+ -c+ -r99 /umsdos_mount_point
 
(You put one for each umsdos mount point in the fstab)
 
This will insure nice operation. A umsdos.fsck is in the making,
so you will be allowed to managed umsdos partition in the same way
other filesystem are, using the generic fsck front end.
 
Hope this helps!
 
/affs.txt
0,0 → 1,188
Amiga filesystems Overview
==========================
 
Not all varieties of the Amiga filesystems are supported for reading and
writing. The Amiga currently knows 6 different filesystems:
 
DOS\0 The old or original filesystem, not really suited for
hard disks and normally not used on them, either.
Supported read/write.
 
DOS\1 The original Fast File System. Supported read/write.
 
DOS\2 The old "international" filesystem. International means that
a bug has been fixed so that accented ("international") letters
in file names are case-insensitive, as they ought to be.
Supported read/write.
 
DOS\3 The "international" Fast File System. Supported read/write.
 
DOS\4 The original filesystem with directory cache. The directory
cache speeds up directory accesses on floppies considerably,
but slows down file creation/deletion. Doesn't make much
sense on hard disks. Supported read only.
 
DOS\5 The Fast File System with directory cache. Supported read only.
 
All of the above filesystems allow block sizes from 512 to 32K bytes.
Supported block sizes are: 512, 1024, 2048 and 4096 bytes. Larger blocks
speed up almost everything with the expense of wasted disk space. The speed
gain above 4K seems not really worth the price, so you don't lose too
much here, either.
 
The muFS (multi user File System) equivalents of the above file systems
are supported, too.
 
Mount options for the AFFS
==========================
 
protect If this option is set, the protection bits cannot be altered.
 
uid[=uid] This sets the uid of the root directory (i. e. the mount point
to uid or to the uid of the current user, if the =uid is
omitted.
 
gid[=gid] Same as above, but for gid.
 
setuid[=uid] This sets the owner of all files and directories in the file
system to uid or the uid of the current user, respectively.
 
setgid[=gid] Same as above, but for gid.
 
mode=mode Sets the mode flags to the given (octal) value, regardless
of the original permissions. Directories will get an x
permission, if the corresponding r bit is set.
This is useful since most of the plain AmigaOS files
will map to 600.
 
reserved=num Sets the number of reserved blocks at the start of the
partition to num. Default is 2.
 
root=block Sets the block number of the root block. This should never
be necessary.
 
bs=blksize Sets the blocksize to blksize. Valid block sizes are 512,
1024, 2048 and 4096. Like the root option, this should
never be necessary, as the affs can figure it out itself.
 
quiet The file system will not return an error for disallowed
mode changes.
 
verbose The volume name, file system type and block size will
be written to the syslog.
 
prefix=path Path will be prefixed to every absolute path name of
symbolic links on an AFFS partition. Default = /
 
volume=name When symbolic links with an absolute path are created
on an AFFS partition, volume will be prepended as the
volume name. Default = "" (empty string).
 
Handling of the Users/Groups and protection flags
=================================================
 
Amiga -> Linux:
 
The Amiga protection flags RWEDRWEDHSPARWED are handled as follows:
 
- R maps to r for user, group and others. On directories, R implies x.
 
- If both W and D are allowed, w will be set.
 
- If both R and S are set, x will be set.
 
- H, P and E are always retained and ignored under Linux.
 
- A is always reset when written.
 
User id and group id will be used unless set[gu]id are given as mount
options. Since most of the Amiga file systems are single user systems
they will be owned by root.
 
Linux -> Amiga:
 
The Linux rwxrwxrwx file mode is handled as follows:
 
- r permission will set R for user, group and others.
 
- w permission will set W and D for user, group and others.
 
- x permission of the user will set S for plain files.
 
- All other flags (suid, sgid, ...) are ignored and will
not be retained.
Newly created files and directories will get the user and group id
of the current user and a mode according to the umask.
 
Symbolic links
==============
 
Although the Amiga and Linux file systems resemble each other, there
are some, not always subtle, differences. One of them becomes apparent
with symbolic links. While Linux has a file system with exactly one
root directory, the Amiga has a separate root directory for each
file system (i. e. partition, floppy disk, ...). With the Amiga,
these entities are called "volumes". They have symbolic names which
can be used to access them. Thus, symbolic links can point to a
different volume. AFFS turns the volume name into a directory name
and prepends the prefix path (see prefix option) to it.
 
Example:
You mount all your Amiga partitions under /amiga/<volume> (where
<volume> is the name of the volume), and you give the option
"prefix=/amiga/" when mounting all your AFFS partitions. (They
might be "User", "WB" and "Graphics", the mount points /amiga/User,
/amiga/WB and /amiga/Graphics). A symbolic link referring to
"User:sc/include/dos/dos.h" will be followed to
"/amiga/User/sc/include/dos/dos.h".
 
Examples
========
 
Command line
mount Archive/Amiga/Workbench3.1.adf /mnt -t affs -o loop,reserved=4
mount /dev/sda3 /Amiga -t affs
 
/etc/fstab example
/dev/sdb5 /d/f affs ro
 
Bugs, Restrictions, Caveats
===========================
 
Quite a few things may not work as advertised. Not everything is
tested, though several hundred MB have been read and written using
this fs.
 
Filenames are truncated to 30 characters without warning.
 
Currently there are no checks against invalid characters (':')
in filenames.
 
Case is ignored by the affs in filename matching, but Linux shells
do care about the case. Example (with /mnt being an affs mounted fs):
rm /mnt/WRONGCASE
will remove /mnt/wrongcase, but
rm /mnt/WR*
will not since the names are matched by the shell.
 
The block allocation is designed for hard disk partitions. If more
than 1 process writes to a (small) diskette, the blocks are allocated
in an ugly way (but the real AFFS doesn't do much better). This
is also true when space gets tight.
 
The bitmap valid flag in the root block may not be accurate when the
system crashes while an affs partition is mounted. There's currently
no way to fix this without an Amiga (disk validator) or manually
(who would do this?). Maybe later.
 
A fsck.affs and mkfs.affs will probably be available in the future.
Until then, you should do
ln -s /bin/true /etc/fs/mkfs.affs
 
It's not possible to read floppy disks with a normal PC or workstation
due to an incompatibility with the Amiga floppy controller.
 
If you are interested in an Amiga Emulator for Linux, look at
 
http://www-users.informatik.rwth-aachen.de/~crux/uae.html
/hpfs.txt
0,0 → 1,27
Linux can read, but not write, OS/2 HPFS partitions.
 
Mount options are the same as for msdos partitions.
 
uid=nnn All files in the partition will be owned by user id nnn.
gid=nnn All files in the partition will be in group nnn.
umask=nnn The permission mask (see umask(1)) for the partition.
conv=binary Data is returned exactly as is, with CRLF's. [default]
conv=text (Carriage return, line feed) is replaced with newline.
conv=auto Chooses, file by file, conv=binary or conv=text (by guessing)
 
There are mount options unique to HPFS.
 
case=lower Convert file names to lower case. [default]
case=asis Return file names as is, in mixed case.
 
nocheck Proceed even if "Improperly stopped flag is set"
 
Case is not significant in filename matching, like real HPFS.
 
 
Command line example
mkdir -p /os2/c
mount -t hpfs -o uid=100,gid=100 /dev/sda6 /os2/c
 
/etc/fstab example
/dev/sdb5 /d/f hpfs ro,uid=402,gid=402,umask=002
/vfat.txt
0,0 → 1,251
USING VFAT
----------------------------------------------------------------------
To use the vfat filesystem, use the filesystem type 'vfat'. i.e.
mount -t vfat /dev/fd0 /mnt
 
No special partition formatter is required. mkdosfs will work fine
if you want to format from within Linux.
 
VFAT MOUNT OPTIONS
----------------------------------------------------------------------
codepage=### -- Sets the codepage for converting to shortname characters
on FAT and VFAT filesystems. By default, codepage 437
is used. This is the default for the U.S. and some
European countries.
iocharset=name-- Character set to use for converting between 8 bit characters
and 16 bit Unicode characters. Long filenames are stored on
disk in Unicode format, but Unix for the most part doesn't
know how to deal with Unicode. There is also an option of
doing UTF8 translations with the utf8 option.
utf8 -- UTF8 is the filesystem safe version of Unicode that
is used by the console. It can be enabled for the
filesystem with this option. If 'uni_xlate' gets set,
UTF8 gets disabled.
uni_xlate -- Translate unhandled Unicode characters to special
escaped sequences. This would let you backup and
restore filenames that are created with any Unicode
characters. Until Linux supports Unicode for real,
this gives you an alternative. Without this option,
a '?' is used when no translation is possible. The
escape character is ':' because it is otherwise
illegal on the vfat filesystem. The escape sequence
that gets used, where u is the unicode character, is:
':', (u & 0x3f), ((u>>6) & 0x3f), (u>>12),
posix -- Allow names of same letters, different case such as
'LongFileName' and 'longfilename' to coexist. This has some
problems currently because 8.3 conflicts are not handled
correctly for Posix filesystem compliance.
nonumtail -- When creating 8.3 aliases, normally the alias will
end in '~1' or tilde followed by some number. If this
option is set, then if the filename is
"longfilename.txt" and "longfile.txt" does not
currently exist in the directory, 'longfile.txt' will
be the short alias instead of 'longfi~1.txt'.
quiet -- Stops printing certain warning messages.
 
Explanation of Native Language Support in the VFAT Filesystem
----------------------------------------------------------------------
There are two different character sets are needed by the vfat
filesystem. The first is the codepage character set. The codepage is
the character set that is used to store short filenames on disk. Its
mount option is 'codepage=437' which 437 is the codepage number.
 
Long filenames are stored in Unicode, but since the Linux filesystem
doesn't deal with 16 bit characters, we need some way of converting
characters. There are a couple options of how to do this. One is to
use the 'utf8' mount option and I will cover that a bit later. The
other is to use the 'iocharset=iso8859-1' mount option where the
iso8859-1 tells the filesystem which character set is used for input
and output. If you are in Russia, you might specify koi8-r here.
If a Unicode character on disk cannot be mapped to anything in the
iocharset, it is replaced with a '?'.
 
The iocharset is used to convert long filenames to and from Unicode.
It is currently implemented. The codepage is used to convert short
filenames to and from the iocharset. This translation is not currently
implemented.
 
If no iocharset is specified and the default is unable to be loaded,
the mount will succeed while falling back to doing no conversions at
all. If a charset is explicity specified and the charset cannot be
loaded, the mount will fail.
 
For the codepage, the default mount option is 'codepage=437'. If a
codepage is explicitly asked for and the load of the character set
fails, the mount will fail. Is no codepage is explicitly asked for
and the load of the character set fails, the load will still succeed.
 
UTF8 is an 8 bit, filesystem safe representation of Unicode. It does
not lose any information in the conversion. However, you need to have
a terminal or a program that knows how to deal with UTF8. The Linux
console can be put into a mode where it will correctly display UTF8
characters. I don't know if there is a similar mode for xterms, but
I don't believe there is. More information about UTF8 can be found
at http://www.unicode.com
 
TODO
----------------------------------------------------------------------
* When only shortnames exist, translate them from the codepage character
set to the iocharset. Currently, translations only occur when longnames
exist. To translate, first convert from codepage to Unicode and then
to the output character set.
 
* Need to add dcache_lookup code msdos filesystem. This means the
directories need to be versioned like the vfat filesystem.
 
* Need to get rid of the raw scanning stuff. Instead, always use
a get next directory entry approach. The only thing left that uses
raw scanning is the directory renaming code.
 
* Fix the Posix filesystem support to work in 8.3 space. This involves
renaming aliases if a conflict occurs between a new filename and
an old alias. This is quite a mess.
 
 
POSSIBLE PROBLEMS
----------------------------------------------------------------------
* vfat_valid_longname does not properly checked reserved names.
* When a volume name is the same as a directory name in the root
directory of the filesystem, the directory name sometimes shows
up empty an empty file.
* autoconv option does not work correctly.
 
BUG REPORTS
----------------------------------------------------------------------
If you have trouble with the VFAT filesystem, mail bug reports to
chaffee@bugs-bunny.cs.berkeley.edu. Please specify the filename
and the operation that gave you trouble.
 
TEST SUITE
----------------------------------------------------------------------
If you plan to make any modifications to the vfat filesystem, please
get the test suite that comes with the vfat distribution at
 
http://www-plateau.cs.berkeley.edu/people/chaffee/vfat.html
 
This tests quite a few parts of the vfat filesystem and additional
tests for new features or untested features would be appreciated.
 
NOTES ON THE STRUCTURE OF THE VFAT FILESYSTEM
----------------------------------------------------------------------
(This documentation was provided by Galen C. Hunt <gchunt@cs.rochester.edu>
and lightly annotated by Gordon Chaffee).
 
This document presents a very rough, technical overview of my
knowledge of the extended FAT file system used in Windows NT 3.5 and
Windows 95. I don't guarantee that any of the following is correct,
but it appears to be so.
 
The extended FAT file system is almost identical to the FAT
file system used in DOS versions up to and including 6.223410239847
:-). The significant change has been the addition of long file names.
Theses names support up to 255 characters including spaces and lower
case characters as opposed to the traditional 8.3 short names.
 
Here is the description of the traditional FAT entry in the current
Windows 95 filesystem:
 
struct directory { // Short 8.3 names
unsigned char name[8]; // file name
unsigned char ext[3]; // file extension
unsigned char attr; // attribute byte
unsigned char lcase; // Case for base and extension
unsigned char ctime_ms; // Creation time, milliseconds
unsigned char ctime[2]; // Creation time
unsigned char cdate[2]; // Creation date
unsigned char adate[2]; // Last access date
unsigned char reserved[2]; // reserved values (ignored)
unsigned char time[2]; // time stamp
unsigned char date[2]; // date stamp
unsigned char start[2]; // starting cluster number
unsigned char size[4]; // size of the file
};
 
The lcase field specifies if the base and/or the extension of an 8.3
name should be capitalized. This field does not seem to be used by
Windows 95 but it is used by Windows NT. The case of filenames is not
completely compatible from Windows NT to Windows 95. It is not completely
compatible in the reverse direction, however. Filenames that fit in
the 8.3 namespace and are written on Windows NT to be lowercase will
show up as uppercase on Windows 95.
 
Note that the "start" and "size" values are actually little
endian integer values. The descriptions of the fields in this
structure are public knowledge and can be found elsewhere.
 
With the extended FAT system, Microsoft has inserted extra
directory entries for any files with extended names. (Any name which
legally fits within the old 8.3 encoding scheme does not have extra
entries.) I call these extra entries slots. Basically, a slot is a
specially formatted directory entry which holds up to 13 characters of
a files extended name. Think of slots as additional labeling for the
directory entry of the file to which they correspond. Microsoft
prefers to refer to the 8.3 entry for a file as its alias and the
extended slot directory entries as the file name.
 
The C structure for a slot directory entry follows:
 
struct slot { // Up to 13 characters of a long name
unsigned char id; // sequence number for slot
unsigned char name0_4[10]; // first 5 characters in name
unsigned char attr; // attribute byte
unsigned char reserved; // always 0
unsigned char alias_checksum; // checksum for 8.3 alias
unsigned char name5_10[12]; // 6 more characters in name
unsigned char start[2]; // starting cluster number
unsigned char name11_12[4]; // last 2 characters in name
};
 
If the layout of the slots looks a little odd, it's only
because of Microsoft's efforts to maintain compatibility with old
software. The slots must be disguised to prevent old software from
panicing. To this end, a number of measures are taken:
 
1) The attribute byte for a slot directory entry is always set
to 0x0f. This corresponds to an old directory entry with
attributes of "hidden", "system", "read-only", and "volume
label". Most old software will ignore any directory
entries with the "volume label" bit set. Real volume label
entries don't have the other three bits set.
 
2) The starting cluster is always set to 0, an impossible
value for a DOS file.
 
Because the extended FAT system is backward compatible, it is
possible for old software to modify directory entries. Measures must
be taken to insure the validity of slots. An extended FAT system can
verify that a slot does in fact belong to an 8.3 directory entry by
the following:
 
1) Positioning. Slots for a file always immediately proceed
their corresponding 8.3 directory entry. In addition, each
slot has an id which marks its order in the extended file
name. Here is a very abbreviated view of an 8.3 directory
entry and its corresponding long name slots for the file
"My Big File.Extension which is long":
 
<proceeding files...>
<slot #3, id = 0x43, characters = "h is long">
<slot #2, id = 0x02, characters = "xtension whic">
<slot #1, id = 0x01, characters = "My Big File.E">
<directory entry, name = "MYBIGFIL.EXT">
 
Note that the slots are stored from last to first. Slots
are numbered from 1 to N. The Nth slot is or'ed with 0x40
to mark it as the last one.
 
2) Checksum. Each slot has an "alias_checksum" value. The
checksum is calculated from the 8.3 name using the
following algorithm:
 
for (sum = i = 0; i < 11; i++) {
sum = (((sum&1)<<7)|((sum&0xfe)>>1)) + name[i]
}
 
3) If there is in the final slot, a Unicode NULL (0x0000) is stored
after the final character. After that, all unused characters in
the final slot are set to Unicode 0xFFFF.
 
Finally, note that the extended name is stored in Unicode. Each Unicode
character takes two bytes.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.