Known problems

This applies to both 2.2.x and 2.3.x/2.4.0-test kernels and to umsdos_progs, and contains simple TODO list and probable order of things to fix. If you think you have argument why something is having wrong priority, or if something is not there at all, please contact me.

  1. 2.4.0-test8 (at least from test6 upward) have a symlink problem -- when symlink is created, they loose last char of symlink name (eg. 'ln -s foo bar' will create symlink to 'foo' named 'ba', and not 'bar' !)
  2. hardlink across directories and related problems - this should be fixed in 2.2.16h diff. Still in queue for 2.4.0-test kernels...
  3. 2.3.99-pre5 -- it seems that changes in VFS broke pseudo-root feature before 2.4 (hint by A.Viro). Will need to rewrite that part - but there seem to be some other problems involved too.
  4. umssync errors when dir/file size approaches UMSDOS_MAXNAME (220 at the moment) and junk at end of each path component. Also problems when PATH_MAX is approached (4095 at the moment). [note for myself: see depth.sh. Also - see what statfs(2) is returning and just put that limit to correct value?]
  5. problems trying to create --linux-.--- file or dir. Should return -EACCESS or something probably.
  6. if file is opened in subdirectory, we can unlink(2) it OK, but after all file in that directory are unlinked, we cannot rmdir(2) the directory itself -- until that file is closed. Shows up as problem for example when compiling kernel on UMSDOS filesystem (it opens dependency file, which 'make mrproper' rm -rf's) [update: according to Al Viro @LKML, that is known bug, which also exists in minixfs for example, and will be fixed in 2.3.x -- 2.2.x is out of luck, sorry]
  7. when rmdir(2)-ing directories under UMSDOS, sometimes underlying FAT is damaged so there are lost clusters left (seems harmless, but nonetheless should never happen! -- lost cluster looks like directory entry, with EMD file correctly deleted beforehand. hmmmm.) if someone can reproduce this at will please contact me!
  8. undefined problems when running UMSDOS over vfat (corrupted long names, files represented as directories and vice versa in UMSDOS etc) - [Note for myself: see kernel/umssync mangle.c diff?]
  9. sometimes we got 'OOPS releasing pseudo-root' message when doing 'ls /DOS' on pseudo-root UMSDOS filesystem. It appears to be harmless, though.
  10. keeping 2.2.x and 2.3.x in sync...

Maybe in the far, far, future

Minor annoyances and things to consider - I don't have an idea what to do with those or don't consider them important. If you think they should be fixed or have any idea about them - drop me a note. Otherwise, they'll probably remain untouched forever... (or until I am bored; but it is probably around same time anyway...)

  1. MS-DOS allows only for directory depth of 10, while UMSDOS can go for more. It would create problems when trying to copy/access UMSDOS directories from MS-DOS (and errors on chkdsk/scandisk etc.).
  2. when unlinking hardlinks, last one remaining (ncount==1) is not denoted back to normal file syntax (mostly cosmetic problem, but that file has all problems of hardlinks, like moving directory under original hardlink, etc)
  3. umsdos_tools, improve the test program to mount the floppy to a different mount point, change to newer mtools, etc.
  4. UMSDOS EMD file format (--linux-.--- file) is NOT same among architectures. Uargh. Still thinking about best way to do it -- it will require breaking compatibility somewhere anyway. Maybe wait for 64bit UID/GID in IA32 kernel to do it and break it all only once?
  5. recreate "UVFAT" -- eg. enable UMSDOS to maintaing long file names not only in EMD, but also in VFAT directory (so long names will also be visible from windows, for example). I expect problems with file mangling, though, so if it's too troublesome I might never get to it...