GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing docs.kernel.org — Read/Write HPFS 2.09 — The Linux Kernel documentation Read/Write HPFS 2.09¶1998-2004, Mikulas Patocka
Credits¶
Jacques Gelinas, MSDos mmap, Inspired by fs/nfs/mmap.c (Jon Tombs 15 Aug 1993) Werner Almesberger, 1992, 1993, MSDos option parser & CR/LF conversion Mount options
File names¶As in OS/2, filenames are case insensitive. However, shell thinks that names are case sensitive, so for example when you create a file FOO, you can use ‘cat FOO’, ‘cat Foo’, ‘cat foo’ or ‘cat F*’ but not ‘cat f*’. Note, that you also won’t be able to compile linux kernel (and maybe other things) on HPFS because kernel creates different files with names like bootsect.S and bootsect.s. When searching for file whose name has characters >= 128, codepages are used - see below. OS/2 ignores dots and spaces at the end of file name, so this driver does as well. If you create ‘a. ...’, the file ‘a’ will be created, but you can still access it under names ‘a.’, ‘a..’, ‘a . . . ‘ etc. Extended attributes¶On HPFS partitions, OS/2 can associate to each file a special information called extended attributes. Extended attributes are pairs of (key,value) where key is an ascii string identifying that attribute and value is any string of bytes of variable length. OS/2 stores window and icon positions and file types there. So why not use it for unix-specific info like file owner or access rights? This driver can do it. If you chown/chgrp/chmod on a hpfs partition, extended attributes with keys “UID”, “GID” or “MODE” and 2-byte values are created. Only that extended attributes those value differs from defaults specified in mount options are created. Once created, the extended attributes are never deleted, they’re just changed. It means that when your default uid=0 and you type something like ‘chown luser file; chown root file’ the file will contain extended attribute UID=0. And when you umount the fs and mount it again with uid=luser_uid, the file will be still owned by root! If you chmod file to 444, extended attribute “MODE” will not be set, this special case is done by setting read-only flag. When you mknod a block or char device, besides “MODE”, the special 4-byte extended attribute “DEV” will be created containing the device number. Currently this driver cannot resize extended attributes - it means that if somebody (I don’t know who?) has set “UID”, “GID”, “MODE” or “DEV” attributes with different sizes, they won’t be rewritten and changing these values doesn’t work. Symlinks¶You can do symlinks on HPFS partition, symlinks are achieved by setting extended attribute named “SYMLINK” with symlink value. Like on ext2, you can chown and chgrp symlinks but I don’t know what is it good for. chmoding symlink results in chmoding file where symlink points. These symlinks are just for Linux use and incompatible with OS/2. OS/2 PmShell symlinks are not supported because they are stored in very crazy way. They tried to do it so that link changes when file is moved ... sometimes it works. But the link is partly stored in directory extended attributes and partly in OS2SYS.INI. I don’t want (and don’t know how) to analyze or change OS2SYS.INI. Codepages¶HPFS can contain several uppercasing tables for several codepages and each file has a pointer to codepage its name is in. However OS/2 was created in America where people don’t care much about codepages and so multiple codepages support is quite buggy. I have Czech OS/2 working in codepage 852 on my disk. Once I booted English OS/2 working in cp 850 and I created a file on my 852 partition. It marked file name codepage as 850 - good. But when I again booted Czech OS/2, the file was completely inaccessible under any name. It seems that OS/2 uppercases the search pattern with its system code page (852) and file name it’s comparing to with its code page (850). These could never match. Is it really what IBM developers wanted? But problems continued. When I created in Czech OS/2 another file in that directory, that file was inaccessible too. OS/2 probably uses different uppercasing method when searching where to place a file (note, that files in HPFS directory must be sorted) and when searching for a file. Finally when I opened this directory in PmShell, PmShell crashed (the funny thing was that, when rebooted, PmShell tried to reopen this directory again :-). chkdsk happily ignores these errors and only low-level disk modification saved me. Never mix different language versions of OS/2 on one system although HPFS was designed to allow that. OK, I could implement complex codepage support to this driver but I think it would cause more problems than benefit with such buggy implementation in OS/2. So this driver simply uses first codepage it finds for uppercasing and lowercasing no matter what’s file codepage index. Usually all file names are in this codepage - if you don’t try to do what I described above :-) Known bugs¶HPFS386 on OS/2 server is not supported. HPFS386 installed on normal OS/2 client should work. If you have OS/2 server, use only read-only mode. I don’t know how to handle some HPFS386 structures like access control list or extended perm list, I don’t know how to delete them when file is deleted and how to not overwrite them with extended attributes. Send me some info on these structures and I’ll make it. However, this driver should detect presence of HPFS386 structures, remount read-only and not destroy them (I hope). When there’s not enough space for extended attributes, they will be truncated and no error is returned. OS/2 can’t access files if the path is longer than about 256 chars but this driver allows you to do it. chkdsk ignores such errors. Sometimes you won’t be able to delete some files on a very full filesystem (returning error ENOSPC). That’s because file in non-leaf node in directory tree (one directory, if it’s large, has dirents in tree on HPFS) must be replaced with another node when deleted. And that new file might have larger name than the old one so the new name doesn’t fit in directory node (dnode). And that would result in directory tree splitting, that takes disk space. Workaround is to delete other files that are leaf (probability that the file is non-leaf is about 1/50) or to truncate file first to make some space. You encounter this problem only if you have many directories so that preallocated directory band is full i.e.: number_of_directories / size_of_filesystem_in_mb > 4. You can’t delete open directories. You can’t rename over directories (what is it good for?). Renaming files so that only case changes doesn’t work. This driver supports it but vfs doesn’t. Something like ‘mv file FILE’ won’t work. All atimes and directory mtimes are not updated. That’s because of performance reasons. If you extremely wish to update them, let me know, I’ll write it (but it will be slow). When the system is out of memory and swap, it may slightly corrupt filesystem (lost files, unbalanced directories). (I guess all filesystem may do it). When compiled, you get warning: function declaration isn’t a prototype. Does anybody know what does it mean? What does “unbalanced tree” message mean?¶Old versions of this driver created sometimes unbalanced dnode trees. OS/2 chkdsk doesn’t scream if the tree is unbalanced (and sometimes creates unbalanced trees too :-) but both HPFS and HPFS386 contain bug that it rarely crashes when the tree is not balanced. This driver handles unbalanced trees correctly and writes warning if it finds them. If you see this message, this is probably because of directories created with old version of this driver. Workaround is to move all files from that directory to another and then back again. Do it in Linux, not OS/2! If you see this message in directory that is whole created by this driver, it is BUG - let me know about it. Bugs in OS/2¶When you have two (or more) lost directories pointing each to other, chkdsk locks up when repairing filesystem. Sometimes (I think it’s random) when you create a file with one-char name under OS/2, OS/2 marks it as ‘long’. chkdsk then removes this flag saying “Minor fs error corrected”. File names like “a .b” are marked as ‘long’ by OS/2 but chkdsk “corrects” it and marks them as short (and writes “minor fs error corrected”). This bug is not in HPFS386. Codepage bugs described above¶If you don’t install fixpacks, there are many, many more... History¶
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |