AW: AW: AW: AW: Hard links on Win2k/XP

>You are still not getting it; the copy/delete/rename is probably _the_ most

>common way applications deal with atomic file updates in a multithread safe

>fashion. Just because some user-space apps choose to update files in an
>unsafe
>manner doesn't mean that _they_ are correct. FWIW, my favorite Win32
>Editor
>(MultiEdit) follows the copy/delete/rename scheme.
>Hardlinks are not suitable for use in this fashion (whether you are talking

>about NTFS or any Linux filesystem). Adding a system option to change
>Subversion's correct behavior is fruitless.

Sorry you are right, I'm not getting it.

What has multithread safety to do with this problem? (multithread safety ->
Locks, Mutexes, Critical Sections, Re-entrance safety .....)

Why should subversion update these files from different threads (at the
"same" time)?

What has this to do with user-space applications (by the way, which
application isn't user-space? Only the OS+Drivers.)?
For Windows I would recommend that an application should update their files
like Microsoft applications. And they overwrite the file (CreateFile(...)
with OPEN_ALWAYS Flag set).

Atomic updates have "only" one advantage: it is atomic, so a crash of
subversion would not corrupt the original file. That is the advantage, and
the price is the loss of the hard links.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 23 13:36:25 2004