[RFC] making TreeTransform more resistant to unexpected failures / writing problems

[Kuno Meyer]

=== 1. About the locking behaviour of Visual Studio ===

On 08.08.2007 01:15, Aaron Bentley wrote:
> Kuno Meyer wrote:
>> The following is my experience with Visual Studio (as my daily working
>> environment) with C#-Projects:
>>
>> - VS *does not* hold locks on source code files (*.cs and others),
>> project files(*.csproj) and solution files (*.sln).
>>
>> Thus everything that needs to be versioned is kept lock-free.
> 
> That means bzr is free to delete them, at all times, right?

VS opens the file, reads its content, closes the file, and adds a 
file-system watcher for being notified of external changes on this file.

When some external program changes the file, VS gets notified. The next 
time when VS gets keyboard focus (= its Window is the topmost one), VS 
displays a MessageBox "File XXX has been changed externally. Reload? 
[Yes][No]"

> 
>> So yes and no:
>> - Intellisense uses source-code parsing for files of the current
>> project/compilation unit
> 
> Yet, you believe it is safe to delete files while they are being parsed?
>  Or are you saying that it's unsafe, but predictably so?

For source code files, nothing gets automatically opened in Visual 
Studio without user interaction.

> 
>>> In Unix, there's no need to remember to close such documents when
>>> running bzr.
>> Windows is not Unix ;-)
> 
> Yes, and that makes Windows infuriating at times.

In the other branch, John Arbash Meinel mentioned a good point about not 
having inode-based locking.



=== 2. About write protection flags ===

My proposals about ignoring write protection flags on existing files to 
be modified are mainly driven by maintaining the same working copy both 
with bazaar and with third-party SW tools actively setting and releasing 
write protection flags and not having a bazaar TT rollback mechanism

> 
>>> Write-protection of files on Unix does not prevent renames, it prevents
>>>  writes.
>> On Windows, it prevents writes and deletion, but not renames. The error
>> happens when deleting the (moved) file from the limbo directory.
> 
> Ah.  My misunderstanding.
 >

[...]

>>>> 2) Newly created or modified files shall not have the write protection
>>>> flag set (enforce chmod u+w)
>>>>
>>>> Would this be acceptable an acceptable behaviour?
>>> That is not necessary or desirable on UNIX.  In fact, we try to preserve
>>> the existing file permissions if at all possible.  How would this help
>>> on Windows?
>> This was my intention for this second proposal (ignoring
>> write-protection flags):
>>
>> 1) Bazaar has a quite nasty behaviour when occurring access problems
>> while tree transformation. Therefore, if we can work around the problem
>> easily (e.g. by ignoring the write protection flag), we should do so.
> 
> To me, this describes ignoring the write protection flag on files that
> already exist.  That sounds fine to me.

This is exactly my proposal.

> 
> Are you saying you were describing ignoring the umask?  Just ignoring
> the umask is not an adequate solution, if we can't cope with files that
> are already u-w.  But if we can cope with u-w files, then surely we
> don't need to ignore the umask.

No, not ignoring the umask, just being able to cope with u-w

> 
>> 2) Write protection in the working copy somehow contradicts the idea of
>> a VCS (especially a distributed VCS), where we have versioning and
>> branching to remember a specific state.
> 
> Users have asked us to preserve file modes.  So we do.  I don't think we
> should change that policy lightly.

Neither do I.

> 
>> And for my personal use case:
>>
>> 3) Write protection of individual files is an (unnecessary) feature of
>> all Microsoft Version Control systems, and I have a lot of crashed
>> transations because of this. Perhaps I'm not the only developer working
>> in this way?
> 
> So far, you've made a case that could justify trying to defeat u-w
> permissions, but I'm not convinced that we should leave it set as u-w
> when the transform is complete.  I don't see any advantage in creating
> files with u+w against the user's wishes, since if we can handle
> existing files with u-w, we can handle new files with u-w.

The reason to leave it at u+w would be that tools observing the write 
protection flag could easily detect a file change.

The known behaviour of (most?) editors offering to override the write 
protection flag is that the file is left unprotected after the write 
operation.

But this perhaps a very Windows-specific behaviour which would astonish 
Unix users. I think, we have here another platform difference -- in this 
case a non-technical one.  ;-)

> 
> And if u-w needs to be handled only for deletions, it would be trivial
> to add support.

Yes, I know this. This is one of the crash reasons in bug 67699, but it 
is not yet investigated whether it is a primary or a secondary fault, 
and whether there are other problems with write protection flags elsewhere.

Kuno