"tahoe mv" deleted my files?

[zooko]

I had a bunch of files in a directory and I wanted to mv them into a subdirectory. So first I ran "tahoe ls" to make sure I could get the names of the files:

$ time ~/playground/tahoe-lafs/bin/tahoe ls --dir-cap=URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq  tahoe:
01 - Balrog Boogie.mp3
02 - Heroines.mp3
03 - Poetic Pitbull Revolutions.mp3
04 - Rag Doll Physics.mp3
05 - D'angelo.mp3
06 - Velvet Embracer.mp3
07 - Gunpowder Chant.mp3
08 - Infralove.mp3
09 - Wedding March for a Bullet.mp3
10 - Qualms of Conscience.mp3
11 - Zodiac Virtues.mp3
12 - Porcelain Judas.mp3
13 - Pink Noise Waltz.mp3
Diablo_Swing_Orchestra-The_Butcher's_Ballroom
Gaetano Verdi
License.txt
Readme - www.jamendo.com .txt
[cover] Diablo Swing Orchestra - The Butcher's Ballroom.jpg
on_ootles

real    0m0.926s
user    0m0.490s
sys     0m0.219s

Then I wrote this bash script that runs "tahoe mv tahoe:$FILENAME tahoe:new_subdir/":

$ for F in ` ~/playground/tahoe-lafs/bin/tahoe ls --dir-cap=URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq  tahoe:` ; do echo $F; time ~/playground/tahoe-lafs/bin/tahoe mv --dir-cap=URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq  "tahoe:${F}" tahoe:Diablo_Swing_Orchestra-The_Butcher\'s_Ballroom/ ; done

01 - Balrog Boogie.mp3
OK

real    0m3.862s
user    0m0.492s
sys     0m0.218s
02 - Heroines.mp3
OK

real    0m2.803s
user    0m0.497s
sys     0m0.215s
03 - Poetic Pitbull Revolutions.mp3
OK

real    0m7.097s
user    0m0.498s
sys     0m0.223s
04 - Rag Doll Physics.mp3
OK

real    0m2.770s
user    0m0.492s
sys     0m0.217s
05 - D'angelo.mp3
OK

real    0m3.383s
user    0m0.501s
sys     0m0.223s
06 - Velvet Embracer.mp3
OK

real    0m2.815s
user    0m0.497s
sys     0m0.217s
07 - Gunpowder Chant.mp3
OK

real    0m3.557s
user    0m0.506s
sys     0m0.232s
08 - Infralove.mp3
OK

real    0m2.846s
user    0m0.505s
sys     0m0.227s
09 - Wedding March for a Bullet.mp3
OK

real    0m3.492s
user    0m0.493s
sys     0m0.219s
10 - Qualms of Conscience.mp3
OK

real    0m3.635s
user    0m0.490s
sys     0m0.217s
11 - Zodiac Virtues.mp3
OK

real    0m2.774s
user    0m0.494s
sys     0m0.220s
12 - Porcelain Judas.mp3
OK

real    0m3.298s
user    0m0.490s
sys     0m0.217s
13 - Pink Noise Waltz.mp3
OK

real    0m3.997s
user    0m0.497s
sys     0m0.223s
Diablo_Swing_Orchestra-The_Butcher's_Ballroom
OK

real    0m2.859s
user    0m0.507s
sys     0m0.226s
Gaetano Verdi
OK

real    0m4.548s
user    0m0.502s
sys     0m0.226s
License.txt
OK

real    0m3.194s
user    0m0.507s
sys     0m0.227s
Readme - www.jamendo.com .txt
OK

real    0m2.772s
user    0m0.500s
sys     0m0.226s
[cover] Diablo Swing Orchestra - The Butcher's Ballroom.jpg
OK

real    0m3.347s
user    0m0.503s
sys     0m0.221s
on_ootles
OK

real    0m3.750s
user    0m0.506s
sys     0m0.227s

All mv's reported OK. So far so good.

Then I went to play the music files from their new locations and... What the heck?? All the .mp3 files are gone, but the other files are still there??

$ time ~/playground/tahoe-lafs/bin/tahoe ls --dir-cap=URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq  tahoe:Diablo_Swing_Orchestra-The_Butcher\'s_Ballroom

Gaetano Verdi
License.txt
Readme - www.jamendo.com .txt
[cover] Diablo Swing Orchestra - The Butcher's Ballroom.jpg
on_ootles

real    0m1.054s
user    0m0.475s
sys     0m0.211s

[davidsarah]

I suspect that you moved the directory Diablo_Swing_Orchestra-The_Butcher's_Ballroom into itself. That is what the bash script literally says to do -- the script would have first moved all of the .mp3 files (which happen to be listed before Diablo_Swing_Orchestra-The_Butcher's_Ballroom) into that directory, and then do:

time ~/playground/tahoe-lafs/bin/tahoe mv --dir-
 cap=URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq "tahoe:Diablo_Swing_Orchestra-The_Butcher's_Ballroom" tahoe:Diablo_Swing_Orchestra-The_Butcher\'s_Ballroom/

which causes said directory to disappear up its own... erm, I mean, become a child of itself.

I don't understand why the subsequent mvs printed OK. They didn't work, as I wouldn't expect since Diablo_Swing_Orchestra-The_Butcher's_Ballroom wouldn't be a child of URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq at that point. It seems like a bug that they printed OK, independent of whether the preceding "move a directory into itself" command should have been allowed.

If you still have a direct cap to the Diablo_Swing_Orchestra-The_Butcher's_Ballroom directory, then it should still exist, with the .mp3 files in it.

A directory being a child of itself isn't a problem per se, in a Tahoe filesystem. OTOH, Unix mv will not allow moving a directory into itself. On cygwin:

$ mv foo foo/
mv: cannot move `foo' to a subdirectory of itself, `foo/foo'

However tahoe mv​ works by doing a PUT operation to create the destination link, and then if that succeeded, doing a DELETE on the source link. It would be possible to check that the source object is not the same as the parent of the destination link, but that only catches some cases that are prevented by Univ mv: you would still be able to move a directory into an indirect descendant, and it isn't clear how to prevent that.

[davidsarah]

Replying to davidsarah:

I don't understand why the subsequent mvs printed OK. They didn't work, as I wouldn't expect since Diablo_Swing_Orchestra-The_Butcher's_Ballroom wouldn't be a child of URI:DIR2:zssplcanct54waahwjjngjyhke:vvdpvxybwc6x7az5i64heqdnql2mdi6fspvxtje4iwzkcvvwukpq at that point.

I meant, they didn't work, as I would expect.

[davidsarah]

Normally, tahoe mv would not result in any data loss because the issuer of the command must have the cap that starts the destination path. In the case described in this bug, however, we delete one of the links in that path, because it is the same as the source link.

Therefore, the potential data loss can be fixed by checking whether any of the destination links are the same as the link that is to be moved. This should match the expectations of users accustomed to Unix mv or moving files in a Windows filesystem, which would fail in the same situation. Note that we are not enforcing that it is impossible to create loops using tahoe mv -- that's not necessary to fix this bug.

The link to be moved must be from a mutable directory, therefore it has an SI. So, the definition of "same as" for links can be "same parent directory SI, and same child name" (comparing child names as Unicode strings without normalization).

The later mvs reporting OK is a separate issue that we haven't investigated yet.

[edit: I think when this comment was written, names were not normalized. Now they are, so the comparison should be with NFC normalization.]

[zooko]

We're not going to finish this in time for v1.6.1, but hopefully for v1.7.0!

[davidsarah]

This also affects the rename operation in SFTP. The approach of comment:4 can also be used there, although it's a different code path.

[davidsarah]

Replying to davidsarah:

This also affects the rename operation in SFTP.

... and FTP, in theory, although the FTP RNFR/RNTO commands are somewhat obscure.

[davidsarah]

Don't know why that last update changed the Version field.

[davidsarah]

​http://tahoe-lafs.org/trac/tahoe-lafs/changeset/4435#file15 fixed one case in which it was possible for tahoe mv to print "OK" after an error (when the source file cannot be removed after the destination file has been successfully added). However, that doesn't appear to be the case involved here, because it would have had to print an error message to stderr first.

Note that tahoe mv uses a PUT then a DELETE of the original file, not a POST with ?t=rename. It would have to be changed to do the latter (now called ?t=relink), as well as changing ?t=relink to do the path check, in order for the approach of comment:4 to work.

[zooko]

I just (accidentally) reproduced this problem in Tahoe-LAFS v1.7.0:

for F in `tahoe ls --node-url=http://127.0.0.1:3456 $RODIRCAP
`; do 
tahoe mv --node-url=http://127.0.0.1:3456 "$RWDIRCAP/${F}" "$RWDIRCAP/papers/;
done

Since "papers" was one of the children of the directory, this resulted in:

tahoe mv --node-url=http://127.0.0.1:3456 "$RWDIRCAP/papers" "$RWDIRCAP/papers/;

Which first linked papers to be a child of papers and then unlinked it from being a child of $RWDIRCAP. Whoops!

(I saw that this was about to happen as the for loop was progressing so I switched to my web browser that was viewing $RWDIRCAP and clicked on the "papers" child that was still listed there, thus retaining a link to papers.)

[davidsarah]

Replying to davidsarah:

​http://tahoe-lafs.org/trac/tahoe-lafs/changeset/4435#file15 fixed one case in which it was possible for tahoe mv to print "OK" after an error (when the source file cannot be removed after the destination file has been successfully added). However, that doesn't appear to be the case involved here, because it would have had to print an error message to stderr first.

In fact that changeset didn't properly fix that case; see #1255. It is not true that it would have had to print an error message to stderr first, so the possibility of this being the explanation for the "OK" output in this ticket should be reconsidered.

[davidsarah]

Reminder that #1579 will probably introduce another case where this can happen.

[davidsarah]

See also ticket:1732#comment:2, which would add a web-API call that might be useful for implementing comment:4.

[warner]

Milestone renamed

[warner]

moving most tickets from 1.12 to 1.13 so we can release 1.12 with magic-folders

[exarkun]

Moving open issues out of closed milestones.

[meejah]

Ticket retargeted after milestone closed