[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug? FSFS revision control

From: Jamie Lawrence <jal_at_jal.org>
Date: 2005-01-27 04:01:31 CET

On Wed, 26 Jan 2005, Dassi, Nasser wrote:

> Hehe, I actually beg to differ (there are always exceptions in
> absolutes).
 
> Simple example: Have you tried opening MS SQL Server data files (LDF,
> MDF) in Notepad when the SQL Server is running? You cannot even open it
> because the process/service has a full-on lock to the files. Mind you
> that technically He-Who-Installs-SQL-Has-Write-Access. Interesting,
> eh?!

Yes, interesting, because in fact, the OS is doing the locking for
SQLserver here.

And yet, in EE756DA4343FE34CA4FBEDE4F7F10ACF028B8CD2@NYC-MAIL01.nar.cornet,
you say:

> Wouldn't it be nice to not blame the OS for everything? Wouldn't it be
> nice if write access was not the *only* way to cause havoc to an
> oh-so-precious version control solution?

In any case, my point stands, for two reasons:

 - Svn is not a continuously running daemon, so OS based file locking is
   not an option, and so your nonsequiter is not even relevant to the
   discussion,
 - If I have write access to MSSQL files, either I also have access to
   shut down the DB, or your OS level (there's that word again) perms
   are so screwed up that I'm equally sure I can find a different way to
   damage the data.

(Probably a third point, but I've not used Windows much at all for a few
years, so this may have changed, but I seem to recall that such locks
were still user accessible, given NTFS write permissions - there was a
utility from sysinternals.com or somewhere similar that would force the
OS to drop the lock.)

> If Subversion employed a similar tactic for FSFS, then at least some
> files (like the revision counter) would not be editable until SVN is
> stopped (read: removed). And although every single sysadmin can lock
> down to this extent, I doubt they'd be the best judge to decide what's
> critical for SVN to operate in a more data-reliable manner.
>
> Yes; "services" are employed in Windows. Yes, system-level processes do
> control (some Oses at least) very low-level data files and a "safe-mode"
> (or super-root) is the only way to truly manipulate the data stored
> within -- although an in-memory process can surely control read-write to
> it (read: lock) while the OS is operating normally.

See above. If you're suggesting someone write some daemon/service
process to attempt to control write access to the data files, I suggest
you look at the architecture of svn; that simply is not a reasonable
addition to the project. (Of course, you're free to write your own.)

If you're not suggesting that, then I respectfully suggest that you
learn a little more security, administration, OSes and application
design before starting a thread like this in an adversarial tone.
 
> Eh? :o)

Eh, no.

-j

-- 
Jamie Lawrence                                        jal@jal.org
Imagination is the one weapon in the war against reality.
  - Jules de Gaultier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 27 04:03:41 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.