On Jan 11 2017, Chris Davies <[email protected]> wrote: > 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.
I would recommend that you inquire at OVH cloud if it is expected that objects that give 404 errors on retrieval are nevertheless included in the bucket listing. This is a bit of anti-feature. >>> 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). Sorry, not a chance. If the backend has lost an object, then chances are that it will happen again. Allowing write access in that situation would be irresponsible. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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.
