Re: [fossil-users] Purging attachments

2018-05-31 Thread Stephan Beal 
On Thu, May 31, 2018 at 10:51 PM, Eugene MIndrov 
wrote:

> Now, if it was against the implementation then it wouldn't have been
> implemented, right?
>

It was implemented only as a last resort, not for daily use. The very real
use case that "needs" to be supported by this feature is that someone
commits copyrighted material into someone else's repo. if i were to make a
copy of copyrighted ebook and post it as an attachment to someone's fossil
wiki, the owner of that wiki _needs_ (for legal reasons) to be able to
banish it. Shunning was not one of Fossil's original features - it was
added to enable that sort of worst-case scenario.


> The main reason I haven't used shun for my purposes is the attachment I
> was trying to nuke was taking 90% of the entire repo and shun leaves
> shunned artifacts lying around, just adding their SHA into the shun list so
> they would be excluded from sync operations.
>

That's not true: see the very first sentence the documentation of the shun
page:

"A shunned artifact will not be pushed nor accepted in a pull and the
artifact content will be purged from the repository the next time the
repository is rebuilt."

You simply need to rebuild the repo after shunning. That won't eliminate it
from any closes, but it will keep them from re-synching it back to your
copy.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Purging attachments

2018-05-31 Thread Eugene MIndrov 
Stephan, I beg to disagree a bit: For starters, I'm well aware of The Scary Purge Warning and its last-resort-ish intended method of usage, and I most definitely don't swing it around on a daily basis, exterminating swathes of artifacts in my repo left and right :) This is actually the very first time in years I've been using Fossil that I need to really obliterate something from historical data. Now, if it was against the implementation then it wouldn't have been implemented, right? But the possibility is there for anyone brave or foolish enough to use. I was simply pointing out an inconsistency or oversight, as I believe that even the most dangerous or uncommon things (probably them foremost), should they be implemented, should be taken on most carefully. The main reason I haven't used shun for my purposes is the attachment I was trying to nuke was taking 90% of the entire repo and shun leaves shunned artifacts lying around, just adding their SHA into the shun list so they would be excluded from sync operations. But on the other hand, I could've rebuilt the local repo afterwards... May be this is the best approach, yes, I'll give it a try, thank you.31.05.2018, 23:05, "Stephan Beal" :On Thu, May 31, 2018 at 8:03 PM, Миндров Евгений  wrote:Well, now I'm in a situation which has been discussed here many times - I need to "unmake" certain file attachment from a repo, make it look like it had never been there.

I know it goes against the core values of Fossil philosophy and it's akin to replacing all fossilized trilobite remains in Paleozoic strata with Oreos so paleontologists would scratch their heads, but anyway.It's not just against the values, it's against the implementation!There is only one way to nuke data in fossil, and it should only be used as a last-resort option, not in day-to-day maintenance. (i've been using fossil since Christmas of 2007 and have never once used this feature.)fossil help purgeprovides these warnings: WARNING: This command can potentially destroy historical data and  leave your repository in a goofy state. Know what you are doing!   Make a backup of your repository before using this command!        FURTHER WARNING: This command is a work-in-progress and may yet    contain bugs. i.e. don't use that feature ever unless you know for a fact that you absolutely need to.Instead, you "want" (but don't REALLY want) the shun feature. It's only accessible in the UI under the Admin pages (the URI is /shun). You enter the UIDs of the artifacts to shun and it will permanently remove them from your repo. Be sure to read the documentation on that page.PS: you _really_ don't want to remove data from your repo unless someone checked in a password, private SSH key, something copyrighted by someone else, or similar cases.-- - stephan bealhttp://wanderinghorse.net/home/stephan/"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

,___fossil-users mailing listfossil-users@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Purging attachments

2018-05-31 Thread Stephan Beal 
On Thu, May 31, 2018 at 8:03 PM, Миндров Евгений 
wrote:

> Well, now I'm in a situation which has been discussed here many times - I
> need to "unmake" certain file attachment from a repo, make it look like it
> had never been there.
>
> I know it goes against the core values of Fossil philosophy and it's akin
> to replacing all fossilized trilobite remains in Paleozoic strata with
> Oreos so paleontologists would scratch their heads, but anyway.
>

It's not just against the values, it's against the implementation!

There is only one way to nuke data in fossil, and it should only be used as
a last-resort option, not in day-to-day maintenance. (i've been using
fossil since Christmas of 2007 and have never once used this feature.)

fossil help purge

provides these warnings:

 WARNING: This command can potentially destroy historical data and 
 leave your repository in a goofy state. Know what you are doing!  
 Make a backup of your repository before using this command!   

 FURTHER WARNING: This command is a work-in-progress and may yet   
 contain bugs.


i.e. don't use that feature ever unless you know for a fact that you
absolutely need to.

Instead, you "want" (but don't REALLY want) the shun feature. It's only
accessible in the UI under the Admin pages (the URI is /shun). You enter
the UIDs of the artifacts to shun and it will permanently remove them from
your repo. Be sure to read the documentation on that page.

PS: you _really_ don't want to remove data from your repo unless someone
checked in a password, private SSH key, something copyrighted by someone
else, or similar cases.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Purging attachments

2018-05-31 Thread Миндров Евгений 
Well, now I'm in a situation which has been discussed here many times - I need 
to "unmake" certain file attachment from a repo, make it look like it had never 
been there.

I know it goes against the core values of Fossil philosophy and it's akin to 
replacing all fossilized trilobite remains in Paleozoic strata with Oreos so 
paleontologists would scratch their heads, but anyway.

I've built a little SQL to find all related artifact UUIDs for a given 
attachment and its history in a repo:

select a.attachid, datetime(a.mtime,'localtime') as created, a.comment
, b.uuid as attach_artifact_uuid
, b1.size as source_size, b1.uuid as source_artifact_uuid
, e.comment
from attachment a
left join blob b on b.rid = a.attachid
left join blob b1 on b1.uuid = a.src
left join event e on e.objid = a.attachid
where a.filename = 'big-bad-file.txt'
order by a.target, a.mtime;

Then I purge all found UUIDs starting with source_artifact_uuid and following 
with values of attach_artifact_uuid, like this:

fossil purge artifacts source_artifact_uuid ... attach_artifact_uuid

But when I re-execute that SQL again, it still returns non-empty data set 
(however, with NULLs for anything related to event or blob data). Investigating 
further I found that indeed all related blob and event data is gone, but 
attachment table still contains data-to-be-purged.

So I got the latest Fossil 2.6 sources and in purge.c file I see (in the 
comments for purge_artifact_list function):

** This routine does the following:
**
  ...
**(6) Remove references to purged artifacts in the following tables:
** (a) EVENT
  ...
** (i) ATTACHMENT
  ...

So it looks like it should delete attachment data, but grepping for "attach" 
text in the file brings back the only match, which is the comment above.
The section of the function with numerous calls of db_multi_exec("DELETE FROM 
some_table WHERE some_condition", zTab) doesn't include anything for dealing 
with attachments.

A bug?

Not a showstopper for me as I can delete remaining attachment data manually, 
but I feel like I should report this.





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users