<div dir="ltr">I don't know whether Bazaar is usable for your use case or not.  I don't think that the specific thing you tried to do should work, but I don't know why you were trying to do that specific thing and whether there are alternatives that would work better with Bazaar.<div><br></div><div>For example, perhaps you could store everything on your encryptfs filesystem and then symlink or bind-mount some things back into the non-encrypted area.  It sounds like the way you currently have it, you're trying to store files from an encrypted filesystem into a Bazaar repository on a non-encrypted filesystem.  If that's the case, the files might as well be on a non-encrypted filesystem, too.  If some of the files you want commit deserve encryption, then the repository should also be on an encrypted filesystem.</div><div><br></div><div>In terms of controlling the working tree, it's about a different issue than yours that Jelmer brought up.  <a href="http://pad.lv/411068" rel="noreferrer" target="_blank" style="color:rgb(17,85,204);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">pad.lv/411068</a> is about mount points specifically.  Bazaar needs to control the working tree so that commands like revert, merge, pull, shelve, etc. can work.  "bzr revert -r 0" should remove all versioned files, directories and symlinks from the working tree.  "bzr revert" should restore them.  But it can't restore a directory that's also a mountpoint.  It doesn't have the data or the privileges to do that.  When you do "rm -r some-directory-inside-the-working-tree", you're doing an operation that "bzr revert" can reverse.  When you change a mountpoint, you're not.  Of course, it's only the *versioned* files that Bazaar needs to control.  It will happily ignore (and preserve) any non-versioned files.</div><div><br></div><div>What you're trying to do is write to files outside the working tree, and Bazaar should not allow that.  It's a distributed version control system, and it would be a security risk if, by making a working tree from someone else's branch, I could overwrite my ~/.bashrc or ~/.profile, etc.  The risk of external software is supposed to be when you run it, not when you simply get a copy of the source code.  This is no different from tar, or any other archiving software.  Only the subdirectory that you extract the archive into should be affected.</div><div><br></div><div>An overlay filesystem would be better than changing bazaar to use copy+delete<span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(i.e. shutil.move)</span> to emulate a rename in one way: the rename is supposed to be an atomic operation that either succeeds or fails, with no chance of partially moving the files.  Copy+delete cannot make that guarantee of an atomic operation, but an overlay filesystem could.</div><div><br></div><div>Aaron</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Sat, Jun 2, 2018 at 3:59 AM Martin Steigerwald <<a href="mailto:martin@lichtvoll.de">martin@lichtvoll.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Aaron.<br>
<br>
Aaron Bentley - 01.06.18, 16:17:<br>
> Bazaar is perfectly happy with symlinks, but if you create a symlink<br>
> to a directory, you should not "bzr add" any of the files in that<br>
> directory. (In fact, I thought we had good check against that). <br>
> Bazaar should not be manipulating files outside its working tree. <br>
> Bazaar is supposed to be in control of the contents of the working<br>
> tree, so whatever files Bazaar is manipulating should actually be in<br>
> the working tree.<br>
> <br>
> os.replace is not a fix for <a href="http://pad.lv/411068" rel="noreferrer" target="_blank">pad.lv/411068</a>: "The operation may fail if<br>
> src and dst are on different filesystems".  Even if it behaved more<br>
> like shutil.move, I disagree that 411068 should be "fixed" by using<br>
> shutil.move or the like.  If you've mounted a directory into your<br>
> working tree, you've taken control away from Bazaar because it can't<br>
> reproduce that state.<br>
<br>
Do you want to tell me that my use case is nothing Bazaar is usable for?<br>
<br>
Why is Bazaar in need to control the working tree? It *never* controls <br>
it. It never is the only software access to a working tree is restricted <br>
to. I do a rm -r some-directory-inside-the-working-tree or something <br>
else does it and the stuff is gone. To me that is quite similar to the <br>
rare case that the Private directory would not be there. It is mounted <br>
on login by pam-ecryptfs. So it is usually just always there when I use <br>
brz. And if it is not there… hey thats my responsibility to be careful <br>
in that case.<br>
<br>
I genuinely believe that software should be behave as intelligent as <br>
required, but not more intelligent like in "I do know better what to use <br>
me for than you do.". However if there is a solid reason why brz cannot <br>
work in such a use case or it would be too cumbersone and error prone to <br>
add such functionality, then I´d be willing to reconsider my use case. <br>
But an artificially limitation IMHO is not it. Of course it is not on me <br>
to require that anyone implements it for me. So unless someone does or I <br>
provide a patch I am stuck with the current situation anyway. I could <br>
probably do some kind of union / overlay thing to make brz believe that <br>
it is working on just one filesystem, while it is not.<br>
<br>
[…]<br>
-- <br>
Martin<br>
<br>
<br>
</blockquote></div></div></div>