Question about auto-refresh and detecting manual edits to standins

[Tessa Starkey]

On Mon, Feb 8, 2010 at 11:57 PM, Anton Markov <anton.markov at gmail.com>wrote:

>
> Given the above discussion, the mtime is the only way to tell if the file
> was modified by something other than bfiles. It may be sufficient to check
> that mtime(placeholder) = mtime(bfile) and to set the placeholder mtime to
> the mtime of the bfile when re-computing. This will not prevent someone
> from
> maliciously faking the mtime, but it should prevent accidental edits.
>

After further investigation, I found different check that  could be made,
without requiring any changes to mtimes.
On bfrefresh and bfadd, a copy of each added/refreshed files is copied to
.hg/bfiles/pending/<filename>/. The name of the copy is the hash of the
bfile. We can check for modification the standin by comparing  the contents
of .hgbfiles/filename  to the name of the file in
.hg/bfiles/pending/<filename>.
This check  would fail if the pending file also was changed to match, but
I'd be impressed if someone could do that by accident. However, this check
would not catch malicious tampering.


> We should also consider if it makes sense to look for explicit tempering in
> the first place. What would a user do if we detect that the placeholder was
> edited? If the editing was truly accidental, the user would just run 'hg
> bfrefresh' to bring the placeholders in line with the real bfiles.


  As  Paul Lambert mentioned on the IRC channel,  the warning would suggest
that the user  revert the standin, to undo any backchannel edits. Running
bfrefresh wouldn't undo the edits to the standins, because bfrefresh only
refreshes bfiles that have been edited since the last time they were
brefreshed. In any case, as Greg said, we don't necessarily want to undo the
modifications,  just make the user aware of them.


- Tessa Starkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100211/c789d2d9/attachment.htm>