This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

A suggestion


Hello,

I greatly enjoy and apprieciate using the Cygwin
system. I find it to be an extremely useful and
important software.

I have  a few suggestions on how it could be further
improved. 

On FAT filesystems, additional features of a Unix file
system could be provided in the Cygwin file hierarchy
by simply creating a file in each directory which
would list additional Unix attributes for each file
and directory, such as a long case-sensitive file
name, drwxrwxrwx, owner and group, along with the
actual FAT filename. 

The attributes and restrictions in the files in the
directories, would however of course only be able to
restrict access to programs accessing files via the
Unix APIs provided by cygwin. However this still is
very useful, for instance the sshd server could be
used to provide a more secure environment. This is why
this sort of feature on top of fat might actually be
very useful for running Unix-type programs. The mounts
of the entire FAT filesystems (such as those under
/mnt) could also be limited via Unix-type permissions
too, to only allow certian users access to files in
the mount of an entire FAT filesystem. This permission
system would by defualt only be used on core
direcories/filesystems mounted under /, as a special
filesystem type, say which could be called FatUX, "FAT
with Unix Extensions". The index file could be called
fatux001.idx. The mounts of the entire FAT (X:\)
filesystems under /mnt would probably be of a plain
FAT type, meaning no additional Unix permissions, and
no index files being modified if a Unix program
accesses files via that mount. However, of course a
user could mount directories as either FAT or FATUX.
The mount command could be used with the FAT or FATUX
type. I will describe later how the fatux001.idx file
can be made unknown to Unix programs without causing
any problem. The 001 is just a version number. This
file would be created if a Unix program creates the
directory via a FATUX mount of the directory, or when
a file is added by such a program, or a permission is
added to an existing file. If a directory is created
by a windows program or a Unix program accessing the
directory via a plain FAT mount, a index file is not
created until one of the events I just mentioned
occurs. 

As files are added by the user in each directory in
the cygwin virtual directory hierarchy system, the
index file will be created and added to, the file will
contian the case-sensitive Unix filename, the actaul
filename under FAT, and the Unix permissions and
ownership. Since, many filenames will be able to be
created with different case but the same characters,
the filename given to Unix programs will have to be
different from the actual filename in FAT, for the
second and all later filenames with same characters
but different case. The first file with say a filename
of "Filename.txt", would be simply created as
"filename.txt" under FAT. However, a second file name
created by a Unix programs with the filename
"FIlename.txt" would be created as "filename~1.txt".
"FILename.txt" would be filename~2.txt and so on. Each
of these files would have an entry in the index file
for the directory, such as this:

filename~2.txt "FILename.txt" -rw-rw-rw- owner group

What if a Unix program tried to create a file named
filename~2.txt? Simple, the file would be created as
filename~3.txt under FAT, but to unix programs it
would be filename~2.txt, since this entry would be
added to the index:

filename~3.txt "filename~2.txt" -rwxrwxrwx owner group

If a filename requested by a Unix program is within
two characters of the length limit of the FAT
filename, and an ~1 addition must be used as above,
two characters will have to be removed from the end of
the filename that is written to FAT. If there are
three characters needed, for a ~10, for instance, 3
characters will be truncated, 4 for ~100, etc.
However, the complete filename requested will of
course be written to the directory index file, the
filename avialable to Unix programs will not be
truncated. However FAT on win95-win98 allows up to
over a hundred characters I believe, so this will not
be too frequantly needed. The filenames which are
truncated when written to FAT, lose some uniqueness
due to the loss of the last few characters, however,
only if those last few characters made the filename
unique will some special attention need to be paid, if
the uniqueness is lost, for instance a file
a....aa.txt becoming a...~1.txt, and there was a
A...aa.txt, it would simply be written to fat as
A...~2.txt (the dots are an abbrievation used for this
example, representing the 100 or so additional,
non-unique (for these two filenames) characters in the
filename). 

Also, the software managing the index files must be
able to gracefully account for the fact Windows
programs (or a Unix program accessing the directory
from a plain FAT mount, not FATUX) may write to the
directory and of course not update the index. If a
file is created by a Windows programs or via a plain
FAt mount, it could be given some defualt permisions,
such the permissions of the directory it is in, when
it is accessed via a FatUX mount. All of the above
would also be used on directories.

Here is an example of a possible index file:

parent /home/user1 "/home/user1"
thisdir /home/user1/myfiles "/home/user1/MyFiles"
filename.txt "Filename.txt" -rwxrwxrwx user1 group1
filename~1.txt "FIlename.txt" -rwxrwxrwx user1 group1
myfile.txt "MyFile.txt" -rwxrwxrwx user1 group1
mydirectory "MyDirectory" drw-rw-rw- user1 group1
mydirectory~1 "MYDIrectory" drw-rw-rw- user1 group1

The first two lines are the mappings for the parent
and the directory itself. The entry for thisdir should
probably also include the "drw-rw-rw- user group"
permissions

Now, back to the fatux001.idx file. This file need not
be visible to Unix programs when a directory is
mounted as FatUX, as in accordance with the system I
will describe above, if a Unix program wants to create
"fatux001.idx", it can, however the file will actaully
be given a different name under the actual FAT
filesystem, fatux001~1.idx, for instance. An entry
then would be added to the index file:

fatux001~1.idx "fatux001.idx" -rwxrwxrwx owner group

Well, what if a Unix program tried to create a
fatux001~1.idx? The file would be created under FAT as
fatux001~2.idx, and this would be added to fatue.idx:

fatue001~2.idx "fatue001~1.idx" -rwxrwxrwx owner group

Of course, if the Unix program is accessing the
directory via a plain FAT mount, and not a FATUX
mount, the fatue001.idx file would be visible to it,
and of course changes made would not update the
fatux001.idx. And of course, in that case, all of the
actual FAT filenames would be seen by the Unix
programs, not the ones in the index file, there would
be no permissions, and no case-sensitive etc, since
its just a plain FAT mount, not a FATUX mount.

A provision may also be made in this index scheme for
links. 

With the file permissions, and ownership features
implemented on FAT, these restrictions would apply to
processes, each process would inherit the file access
permissions of the user it is running as. As well,
commands such as su and useradd, chmod, chown, and
other such common unix commands would be much more
useful and meaningful on Win98 systems, thus creating
a much more genuine looking Unix environment. Many
users should be able to be easily created and added to
passwd.

I  think implementing this system would be well worth
the benefits, and would be useful to a large number of
users.





__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]