Re: [PATCH] ls & "magic" cygdrive dir (was: RE: cygdrive stuff)

[Li-Kai Liu <news at likai dot net>]

Ronald Landheer wrote:

>What's in a name? I have no problem with just keeping the "fhandlers" as 
>it's still the file system we're handling - be it virtual, magic or 
>otherwise. I see no reason to complicate matters with naming conventions 
>for obscure reasons. Anyone who takes a look at the source code and/or 
>the docs will know how it works, and whatever I implement will be 
>commented in the code, and will probably be accompanied by a file "How 
>do magic dirs work?". Other than that, this thread documents the design 
>in detail, and if there's a lot of questions about it - which I highly 
>doubt, because it's a Cygwin internal matter we're talking about - there 
>can always be an FAQ entry. We'd need one if we'd call it dhandlers or 
>mhandlers too, if we'd need one at all.
>
>The key to clear programming is not in changing a letter of a name: it's 
>in the documentation of both the source code and its functionality. 
>Whether you call it fhandlers or dhandlers (or mhandlers) is, IMHO, a 
>non-issue.
>
the way fhandler reflect to me is that it handles specific files in the 
filesystem. and fhandler classes often have basic file operations (open, 
read, write, seek, even ioctl) in mind. the point is, fhandler seems to 
me more like a device driver than file system. true, it doesn't matter 
whether we debate over names like dhandler or mhandler, even fshandler 
is a good name. clarity is not what i stress here, by the way.

however, files and file systems are two different concepts! fhandler 
takes care of device files, and fshandler takes care of file system, 
visibility, and traversal. of course you could make fhandler take care 
of file system's work, but i can tell you, by confusing over the two 
different concepts and merge them to one, you'll end up having a really 
messy ugly thing. now, talk about programming, i think organization and 
architectural design is above all things. of course, organization 
implies clarity ... well, if you do want to rant about my obsession with 
clarity ... ~_~

maybe i didn't say it in a recognizable fashion last time, but i do hope 
to separate *file* handling with *file system* handling.

if cygwin's goal is to implement a unix system on windows, then why 
don't we do what unix does? in my opinion, a file object should not need 
to worry about its location/path/attribute. all it needs to care is 
input and output. in turn, an inode (file system object) should not 
worry about input and output. it just takes care of where the file 
object is, the file type, and its attribute.

apparently it is not the way it is right now in cygwin. :(

i know that this might sound overly complicated to people. besides, it 
sounds more like we're implementing an entire operating system. in some 
sense, it is true. whoever decided to have a separate file system in 
cygwin then in win32 in the first place should also know where this 
ends. you don't do things half-way done. i mean, i'm not forcing anybody 
to code the way i want them to. i'll genuinely code this thing if I know 
that people like my idea and so it won't end up being hated and discarded.

liulk



--
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/