"tahoe mv" deleted my files? #943

New issue

Open

opened 2010-02-08 23:34:54 +00:00 by zooko · 16 comments

zooko commented

2010-02-08 23:34:54 +00:00

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

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 ```

zooko added the

labels 2010-02-08 23:34:54 +00:00

zooko added this to the undecided milestone 2010-02-08 23:34:54 +00:00

daira commented

2010-02-09 02:36:23 +00:00

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]source:src/allmydata/scripts/tahoe_mv.py 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.

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 `mv`s 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]source:src/allmydata/scripts/tahoe_mv.py 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.

daira commented

2010-02-09 02:37:43 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac/issues/943#issuecomment-376179): > I don't understand why the subsequent `mv`s 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.

daira modified the milestone from undecided to 1.6.1

2010-02-15 20:31:25 +00:00

daira commented

2010-02-16 05:56:56 +00:00

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 with~~out~~ normalization).

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

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

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 with~~out~~ normalization). The later `mv`s reporting OK is a separate issue that we haven't investigated yet. [I think when this comment was written, names were not normalized. Now they are, so the comparison should be with NFC normalization.]edit:

zooko commented

2010-02-22 05:14:34 +00:00

Author

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

zooko modified the milestone from 1.6.1 to 1.7.0

2010-02-22 05:14:34 +00:00

daira added

p/critical

and removed

p/major

labels 2010-03-02 01:25:52 +00:00

daira self-assigned this 2010-03-02 01:25:52 +00:00

daira commented

2010-03-07 21:31:40 +00:00

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

This also affects the rename operation in SFTP. The approach of [comment:376182](/tahoe-lafs/trac/issues/943#issuecomment-376182) can also be used there, although it's a different code path.

daira commented

2010-03-07 21:42:07 +00:00

Replying to davidsarah:

This also affects the rename operation in SFTP.

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

Replying to [davidsarah](/tahoe-lafs/trac/issues/943#issuecomment-376188): > This also affects the rename operation in SFTP. ... and FTP, in theory, although the FTP `RNFR`/`RNTO` commands are somewhat obscure.

zooko modified the milestone from 1.7.0 to eventually

2010-05-16 23:40:25 +00:00

daira modified the milestone from eventually to soon

2010-05-17 02:14:40 +00:00

daira added

v/1.6.1

and removed

v/1.6.0

labels 2010-06-10 15:48:38 +00:00

daira modified the milestone from soon to 1.8.0

2010-06-10 15:48:38 +00:00

daira commented

2010-06-10 15:49:57 +00:00

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

daira added

v/1.6.0

and removed

v/1.6.1

labels 2010-06-10 15:49:57 +00:00

daira commented

2010-06-10 16:23:24 +00:00

(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:376182 to work.

(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:376182](/tahoe-lafs/trac/issues/943#issuecomment-376182) to work.

daira modified the milestone from 1.8.0 to 1.7.1

2010-06-12 20:54:33 +00:00

zooko commented

2010-06-28 22:46:12 +00:00

Author

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.)

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.)

daira modified the milestone from 1.7.1 to 1.8β

2010-07-17 03:47:17 +00:00

daira modified the milestone from 1.8β to 1.9.0

2010-08-10 03:42:18 +00:00

daira commented

2010-11-10 01:46:36 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac/issues/943#issuecomment-376198): > <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.

daira modified the milestone from 1.9.0 to soon

2011-08-02 15:55:19 +00:00

daira modified the milestone from soon to 1.10.0

2011-08-15 04:23:17 +00:00

daira commented

2011-11-18 02:00:57 +00:00

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

daira commented

2012-05-10 01:07:31 +00:00

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

See also ticket:1732#comment:2, which would add a web-API call that might be useful for implementing [comment:376182](/tahoe-lafs/trac/issues/943#issuecomment-376182).