Re: path name limits

On Fri, 25 Oct 2002, Matthias Paul wrote:

> The reason for this is that these old DR DOS issues were still

The same work would need to be done in the FreeDOS kernel actually -
however reversed.

> Since most applications have fixed internal paths lengths,
> we would need a slightly modified SUBST and kernel to work

You would need to make known to the kernel that the right-hand drive
letter is a logical one, too, instead of a physical one. (Hence your
reference to the flags??)

You can bypass these problems using UNC, e.g.:

> Y: = C:\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2
> Z: = Y:\A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z

Z: = \\?\-Y:\A\B\ ...

It is actually derived from WinNT4's filename-mangle-bypass notation:
\\?\C:\...

Now you won't need to tag those entries particularily in order to let the
kernel know that the right-hand drive letter is to look up as logical
drive letter again (transitiveness).

Because \\? is in invalid UNC path otherwise, you can play nice things
with it. Also, because it's UNC now, most programs should keep their hands
(er, bytes) away from these drives.

> any file or directory can have a password, access rights, and
> ownership associations assigned to it. The password and the
> corresponding access rights are stored encrypted in some
> of the ten reserved entries in the directory entries in the

I agree with Bart here.
But there is still the UMSDOS variant or even OS/2 variant:
Store such stuff in a special file (per directory or per drive).
Maybe there is one way to "mark" directory entries with an unique ID
(that's not the cluster number) in order to catch corruption caused by
programs bypassing the kernel, but poking the file system and are not
aware of those special attributes.
UMSDOS uses the file's extension as unique ID; for OS/2 I don't know, but
I guess they prevent direct alteration of the filesystem, hence, they can
use the cluster number.

An access password without encryption is nice, but too primitive,
especially because the hackery scene more and more goes "point your IE to
site ABC, download tool XYZ, run it". See: The WinNuke-bug was kinky,
until someone made a click'n'shoot utility handled by even 3-years old
children (as it generated a default IP on startup by random number, so all
you needed to do was click the "Nuke"-button, then it re-generated the IP,
and you've clicked "Nuke" again ...); but then the blue-screen count was
about one per hour.

I would actually prefer having something like this:
You, the user, tell the kernel passwords beforehand, which are
automatically applied to a range of files/directories on access. If you
enter the wrong or none password, you get garbish. Easy, nifty, few
traces, no checksums, no permission denied. However, would need
block-encryption, passwords need to be kept in memory, automatization is
limited, performance drop.

Bye,

-- 

Steffen Kaiser