#826 new defect

Rename action in WUI has no confirmation for clobbering another entry

Reported by: davidsarah Owned by:
Priority: major Milestone: soon
Component: code-frontend-web Version: 1.5.0
Keywords: usability docs Cc:
Launchpad Bug:


If you rename a directory entry in the WUI, and the destination name already exists as a child of that directory, then the preexisting child will be clobbered without confirmation (even if it is an entry for a directory).

[This does not actually lose data: you can use the Back button to go to the earlier version of the directory page in the browser's cache, get the read cap for the file whose entry was clobbered, and add it back. A user who doesn't have a clear mental model of the distinction between files and directory entries, and the fact that pressing Back normally reads from cache, would probably not know that they can do this, though.]

There is an undocumented 'replace' parameter to the ?t=rename webapi operation, mentioned in http://allmydata.org/trac/tahoe/ticket/705#comment:16 ; replace=false will cause a failure if the destination entry already exists.

To close this ticket, add appropriate UI to the 'rename' page that controls whether the 'replace' parameter is true or false. Also document this parameter in source:docs/frontends/webapi.txt#L929

Change History (2)

comment:1 Changed at 2010-02-01T19:52:34Z by davidsarah

  • Milestone changed from undecided to 1.7.0

comment:2 Changed at 2010-06-18T23:47:48Z by zooko

  • Milestone changed from 1.7.0 to soon
Note: See TracTickets for help on using tickets.