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]

Re: Charles: Fwd: Re: NDBM & ODBM on Cygwin?


--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> 
> 
> Nicholas Wourms wrote:
> 
> >>>Sure -- figure out a way to implement hardlinks on FAT.
> >>>
> >>It's called cross linked files... and checkdisk will 'fix' it :[.
> >>
> >>
> > 
> > Then the only way to get around that is to emulate hard links, instead
> of
> > actually creating a cross-linked file?
> 
> 
> ndbm requires that both the .pag file and .dir file have exactly the 
> same timestamp.  Since gdbm actually implements "ndbm" functionality by 
> putting a "native format" gdbm database into .pag, it simply hardlinks 
> the .dir file to .pag, thus insuring that the timestamps are always 
> identical -- and that file accesses are atomic.
> 
> There may be other ways to solve the underlying problem -- but that 
> would make cygwin-gdbm's ndbm-emulation different from the rest of the 
> world.  And, since any algorithm mod would change the on-disk format of 
> gdbm-in-ndbm-mode, I doubt it would be accepted as a global mod.
> 
> For instance, we could instead have two separate files, one is empty. 
> All file accesses to .pag are accompanied by 'touch .dir' -- but that's 
> not atomic, AND .dir is no longer itself a valid database.  The folks on
> 
> linux certainly don't want to see that backwards incompatible format 
> change -- just to help US with a problem that only appears in certain 
> cases (using ndbm emulation on FAT drives).

That seems to be one solution, I agree.  Perhaps the section of code
dealing with the database format could be ifdef'ed to do this.  With the
caveat that and movement of the database to another machine would require
a database dump due to differences in formats.  Still there ought to be a
way to trick cygwin, and thus any applications using cygwin's api, into
thinking that the link created is an actual "hard link".  In this way we
force windows to accomodate us instead of the other way around.  Look at
it from my perspective, I've been loathe to upgrade to nt and ntfs due to
the multitude of "issues" people encounter with ntsec.  Don't get me
wrong, I appreciate the effort, but it seems like the documented methods
of setting up ntsec do not work OOTB for a lot of people, requiring a
massive research of the ml archives.  If I ever do it, I promise I'll
document all the exceptions w/ solutions I find in the ml archives,
because IMHO, setting up ntsec should be easy.  Yes, I'm sure it is easy
to some of you, but the amount of requests for help leads me to conclude
that it is not a seamless as it could be.  Again, my experience with NT
programming is extremely limited, so I can offer only observations at this
point.  My solution: a consilidation of the various exceptions and their
solutions should be documented in a single place.  Also, some of the more
common "gotchas" regarding services & ntsec should be covered as well. 
Perhaps a special section in the FAQ covering these solutions would be
advisable.  Contrary to what Chris believes, I am of the school that
believes that a FAQ can never be too big and that there is always room for
more documentation.  But I digress, I guess my point is that I hope
someone, who is more familiar then I, might considier seeing if this
emulation is possible and how best to do it.  Considier this would mean
one less issue to have to deal with when porting applications requiring
hard links.  If not, then oh well...  But don't complain if people like
Jakko turn off support for operations involving hard links.  They are,
after all, primarily concerned with the port running on their own
machines.  I guess what I'm trying to say is:
"Just because we are using 9x doesn't mean you have to treat us like
rubbish..."  (Just Kidding, but you see how we might feel)  :-)

Cheers,
Nicholas

P.S. - Before you say so, I am aware of the limitations of the FAT
filesystem.  All I'm saying is that there is always a solution to a
problem.  This solution shouldn't require having to switch operating
systems.  This is mainly a persuasive argument aimed at someone thinking
outside the norms and figuring out a way to do this so that everyone will
be happy.  I'm sure people balked back in '96 at the thought of a posix
emulation layer in windows.  I'm sure they said, "Why don't you just use
linux, it's free and it already works".  Look at how far Cygwin has come
today, and judging by slashdot, this perception has changed as well.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.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]