On Wednesday, 11 January 2017 18:20:14 UTC, Nikolaus Rath wrote:
>
> What backend are you using? For most sane backends, a regular fsck.s3ql 
> should fix these issues. 
>
>
I'm using swiftks to OVH Cloud (not Hubic). Fsck doesn't fix the problem - 
this mount and crash occurred shortly after my previous fsck.

 

> > However, in this 
> > particular use case I don't think the filesystem should crash. 
>
> You are right, and it actually should not do that but enter "failsafe" 
> mode instead (file system becomes read-only). Could you please file an 
> issue at https://bitbucket.org/nikratio/s3ql/issues? I'll try to get 
> this fixed in the next release


I'll certainly file an issue. In most cases I'd agree with you, but in this 
specific case of there being no data available for a file being deleted I'd 
personally really prefer the filesystem just to carry on (in read/write 
mode).

I'm trying s3ql_verify next, to see if that picks up any issues.

Thanks,
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to