UnrecoverableFileError message should say which file it refers to #1234

New Issue

tahoe-lafs · 2010-10-28T23:23:19Z

davidsarah commented

2010-10-28 23:23:19 +00:00

zooko on irc:

sigh, I am experiencing failure using the pub test grid :-/

My top-level directory contains some subdir or subdir of subdir which is unrecoverable.

Therefore, as far as I know, the Tahoe-LAFS UIs provide almost no way to proceed.

I can't deep-repair, I can't cp -r to recover the recoverable stuff.

Maybe I can deep-check to learn which one is unrecoverable ...

The current error message is:

UnrecoverableFileError: the directory (or mutable file) could not
be retrieved, because there were insufficient good shares. This
might indicate that no servers were connected, insufficient servers
were connected, the URI was corrupt, or that shares have been lost
due to server departure, hard drive failure, or disk corruption.
You should perform a filecheck on this object to learn more.

/tahoe-lafs/trac-2024-07-25/issues/5817#comment:4 mentions this problem, but that ticket is mainly about having deep-check continue on error. Giving information about which file is unrecoverable (the cap, and the filename if known) would be useful in more circumstances than just deep-check.

Note that because of #625, we need a write cap to repair mutable files/directories. Otherwise I would suggest diminishing the cap in the message to a read or verify cap (since the error message channel might be more vulnerable to cap leakage). As it is, the user needs the write cap, at least for mutable objects.

zooko on irc: > sigh, I am experiencing failure using the pub test grid :-/ > My top-level directory contains some subdir or subdir of subdir which is unrecoverable. > Therefore, as far as I know, the Tahoe-LAFS UIs provide almost no way to proceed. > I can't deep-repair, I can't cp -r to recover the recoverable stuff. > Maybe I can deep-check to learn which one is unrecoverable ... The current error message is: ``` UnrecoverableFileError: the directory (or mutable file) could not be retrieved, because there were insufficient good shares. This might indicate that no servers were connected, insufficient servers were connected, the URI was corrupt, or that shares have been lost due to server departure, hard drive failure, or disk corruption. You should perform a filecheck on this object to learn more. ``` [/tahoe-lafs/trac-2024-07-25/issues/5817](/tahoe-lafs/trac-2024-07-25/issues/5817)#comment:4 mentions this problem, but that ticket is mainly about having deep-check continue on error. Giving information about which file is unrecoverable (the cap, and the filename if known) would be useful in more circumstances than just deep-check. Note that because of #625, we need a write cap to repair mutable files/directories. Otherwise I would suggest diminishing the cap in the message to a read or verify cap (since the error message channel might be more vulnerable to cap leakage). As it is, the user needs the write cap, at least for mutable objects.

tahoe-lafs added the

labels 2010-10-28 23:23:19 +00:00

tahoe-lafs added this to the 1.9.0 milestone 2010-10-28 23:23:19 +00:00

davidsarah commented

2010-10-28 23:26:10 +00:00

Replying to davidsarah:

[...] As it is, the user needs the write cap, at least for mutable objects.

Only when it is available to the operation that failed, of course.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/6296): > [...] As it is, the user needs the write cap, at least for mutable objects. Only when it is available to the operation that failed, of course.

tahoe-lafs modified the milestone from 1.9.0 to soon

2011-08-13 23:31:46 +00:00

Sign in to join this conversation.