JakeHillion/storj
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
cd9feb6d09
storj/cmd/uplink/cmd_cp_test.go

581 lines
23 KiB
Go
Raw Normal View History

cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
// Copyright (C) 2021 Storj Labs, Inc.
// See LICENSE for copying information.
package main
import (
"testing"
cmd/uplink: only use new code path for uploads downloads still need the old copy code because they aren't parallel in the same way uploads are. revert all the code that removed the parallel copy, only use the non-parallel copy for uploads, and add back the parallelism and chunk size flags and have them set the maximum concurrent pieces flags to values based on each other when only one is set for backwards compatibility. mostly reverts 54ef1c8ca23cac8c4ab803f6123ab2d06fb84d4c Change-Id: I8b5f62bf18a6548fa60865c6c61b5f34fbcec14c
2023-06-08 16:42:03 +01:00
"github.com/stretchr/testify/require"
"storj.io/common/memory"
cmd/uplinkng: become cmd/uplink Change-Id: If426c32219d32044d715ab6dfa9718807f32cb9f
2022-01-06 19:55:46 +00:00
"storj.io/storj/cmd/uplink/ultest"
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
)
func TestCpDownload(t *testing.T) {
state := ultest.Setup(commands,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.WithFile("/home/user/file1.txt", "local"),
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
ultest.WithFile("sj://user/file1.txt", "remote"),
)
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("Basic", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/file1.txt", "/home/user/file2.txt").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "remote"},
)
})
t.Run("Overwrite", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/file1.txt", "/home/user/file1.txt").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "remote"},
)
})
t.Run("Relative", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/file1.txt", "").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local"},
ultest.File{Loc: "file1.txt", Contents: "remote"},
)
state.Succeed(t, "cp", "sj://user/file1.txt", ".").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local"},
ultest.File{Loc: "file1.txt", Contents: "remote"},
)
state.Succeed(t, "cp", "sj://user/file1.txt", "./").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local"},
ultest.File{Loc: "file1.txt", Contents: "remote"},
)
})
t.Run("Recursive", func(t *testing.T) {
state := ultest.Setup(commands,
ultest.WithFile("sj://user/file1.txt", "data1"),
ultest.WithFile("sj://user/folder1/file2.txt", "data2"),
ultest.WithFile("sj://user/folder1/file3.txt", "data3"),
ultest.WithFile("sj://user/folder1/folder2/file4.txt", "data4"),
ultest.WithFile("sj://user/folder1/folder2/file5.txt", "data5"),
)
state.Succeed(t, "cp", "sj://user", "/home/user/dest", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/dest/file1.txt", Contents: "data1"},
ultest.File{Loc: "/home/user/dest/folder1/file2.txt", Contents: "data2"},
ultest.File{Loc: "/home/user/dest/folder1/file3.txt", Contents: "data3"},
ultest.File{Loc: "/home/user/dest/folder1/folder2/file4.txt", Contents: "data4"},
ultest.File{Loc: "/home/user/dest/folder1/folder2/file5.txt", Contents: "data5"},
)
state.Succeed(t, "cp", "sj://user/folder1", "/home/user/dest", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/dest/folder1/file2.txt", Contents: "data2"},
ultest.File{Loc: "/home/user/dest/folder1/file3.txt", Contents: "data3"},
ultest.File{Loc: "/home/user/dest/folder1/folder2/file4.txt", Contents: "data4"},
ultest.File{Loc: "/home/user/dest/folder1/folder2/file5.txt", Contents: "data5"},
)
state.Succeed(t, "cp", "sj://user/fo", "/home/user/dest", "--recursive").RequireLocalFiles(t)
})
cmd/uplinkng: add ranged download This change adds the ability to download byte ranges to uplinkng. Extended the uplinkng Filesystem interface with Stat method and an OpenOptions struct as parameter for the Open method. Also added a few tests for the ranged download Change-Id: I89a7276a75c51a4b22d7a450f15b3eb18ba838d4
2021-10-26 11:49:03 +01:00
t.Run("Range", func(t *testing.T) {
state := ultest.Setup(commands,
ultest.WithFile("sj://user/file-for-byte-range", "abcdefghijklmnopqrstuvwxyz"),
)
// multiple byte ranges not supported
state.Fail(t, "cp", "sj://user/file-for-byte-range", "/home/user/dest/file-for-byte-range", "--range", "bytes=0-1,2-3").RequireFailure(t).RequireLocalFiles(t)
state.Succeed(t, "cp", "sj://user/file-for-byte-range", "/home/user/dest/file-for-byte-range", "--range", "bytes=0-2").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/dest/file-for-byte-range", Contents: "abc"},
)
state.Succeed(t, "cp", "sj://user/file-for-byte-range", "/home/user/dest/file-for-byte-range", "--range", "bytes=-1").RequireLocalFiles(t,
ultest.File{Loc: "/home/user/dest/file-for-byte-range", Contents: "z"},
)
// invalid range
state.Fail(t, "cp", "sj://user/file-for-byte-range", "/home/user/dest/file-for-byte-range", "--range", "bytes=0,-1").RequireFailure(t).RequireLocalFiles(t)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
}
cmd/uplink: only use new code path for uploads downloads still need the old copy code because they aren't parallel in the same way uploads are. revert all the code that removed the parallel copy, only use the non-parallel copy for uploads, and add back the parallelism and chunk size flags and have them set the maximum concurrent pieces flags to values based on each other when only one is set for backwards compatibility. mostly reverts 54ef1c8ca23cac8c4ab803f6123ab2d06fb84d4c Change-Id: I8b5f62bf18a6548fa60865c6c61b5f34fbcec14c
2023-06-08 16:42:03 +01:00
func TestCpPartSize(t *testing.T) {
c := newCmdCp(nil)
// 1GiB file, should return 64MiB
partSize, err := c.calculatePartSize(memory.GiB.Int64(), c.parallelismChunkSize.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.MiB*64, partSize)
// 640 GB file, should return 64MiB.
partSize, err = c.calculatePartSize(memory.GB.Int64()*640, c.parallelismChunkSize.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.MiB*64, partSize)
// 640GiB file, should return 128MiB.
partSize, err = c.calculatePartSize(memory.GiB.Int64()*640, c.parallelismChunkSize.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.MiB*128, partSize)
// 1TiB file, should return 128MiB.
partSize, err = c.calculatePartSize(memory.TiB.Int64(), c.parallelismChunkSize.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.MiB*128, partSize)
// 1.3TiB file, should return 192MiB.
partSize, err = c.calculatePartSize(memory.GiB.Int64()*1300, c.parallelismChunkSize.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.MiB*192, partSize)
// should return 1GiB as requested.
partSize, err = c.calculatePartSize(memory.GiB.Int64()*1300, memory.GiB.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.GiB, partSize)
// should return 192 MiB and error, since preferred is too low.
partSize, err = c.calculatePartSize(memory.GiB.Int64()*1300, memory.MiB.Int64())
require.Error(t, err)
require.Equal(t, "the specified chunk size 1.0 MiB is too small, requires 192.0 MiB or larger", err.Error())
require.Zero(t, partSize)
// negative length should return 64MiB part size
partSize, err = c.calculatePartSize(-1, c.parallelismChunkSize.Int64())
require.NoError(t, err)
require.EqualValues(t, memory.MiB*64, partSize)
}
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
func TestCpUpload(t *testing.T) {
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
state := ultest.Setup(commands,
ultest.WithFile("/home/user/file1.txt", "local"),
ultest.WithFile("sj://user/file1.txt", "remote"),
)
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("Basic", func(t *testing.T) {
state.Succeed(t, "cp", "/home/user/file1.txt", "sj://user/file2.txt").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "local"},
)
})
t.Run("Overwrite", func(t *testing.T) {
state.Succeed(t, "cp", "/home/user/file1.txt", "sj://user/file1.txt").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "local"},
)
})
cmd/uplink: supporty expires in copy When copying an object from cli you can now set the expiry. It uses the same datetime format as restricting access grants. Closes https://github.com/storj/storj/issues/4595 Change-Id: Icab73a64a9589817d6bc6d702b765b166ca1350d
2022-03-07 00:54:48 +00:00
t.Run("Expires", func(t *testing.T) {
state.Succeed(t, "cp", "--expires", "+4h", "/home/user/file1.txt", "sj://user/file1.txt").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "local"},
)
state.Succeed(t, "cp", "--expires", "-4h", "/home/user/file1.txt", "sj://user/file1.txt").RequireRemoteFiles(t)
})
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("EdgeCases", func(t *testing.T) {
state.Succeed(t, "cp", "/home/user/file1.txt", "sj://user").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "local"},
)
state.Succeed(t, "cp", "/home/user/file1.txt", "sj://user/foo").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote"},
ultest.File{Loc: "sj://user/foo", Contents: "local"},
)
state.Succeed(t, "cp", "/home/user/file1.txt", "sj://user/foo/").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote"},
ultest.File{Loc: "sj://user/foo/file1.txt", Contents: "local"},
)
})
t.Run("Recursive", func(t *testing.T) {
state := ultest.Setup(commands,
ultest.WithBucket("user"),
ultest.WithFile("/home/user/file1.txt", "data1"),
ultest.WithFile("/home/user/file2.txt", "data2"),
ultest.WithFile("/home/user/file3.txt", "data3"),
)
state.Succeed(t, "cp", "/home/user", "sj://user/folder", "--recursive").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/folder/file1.txt", Contents: "data1"},
ultest.File{Loc: "sj://user/folder/file2.txt", Contents: "data2"},
ultest.File{Loc: "sj://user/folder/file3.txt", Contents: "data3"},
)
state.Succeed(t, "cp", "/home/user/fi", "sj://user/folder", "--recursive").RequireRemoteFiles(t)
})
cmd/uplink: bring back --metadata for cp command At some point uplink cli lost ability to set metadata. This change brings back this functionality for 'cp' operation. https://github.com/storj/storj/issues/3848 Change-Id: Ia5f60eb577fcab8a38d94730d8cdc6e0338d3b46
2022-05-13 11:21:01 +01:00
t.Run("Metadata", func(t *testing.T) {
state.Succeed(t, "cp", "--metadata", "{\"key\":\"value\"}", "/home/user/file1.txt", "sj://user/file_with_metadata.txt").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote"},
ultest.File{Loc: "sj://user/file_with_metadata.txt", Contents: "local", Metadata: map[string]string{
"key": "value",
}},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
}
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
func TestCpRecursiveDifficult(t *testing.T) {
t.Run("Success", func(t *testing.T) {
state := ultest.Setup(commands,
ultest.WithFile("sj://user/dot-dot/../../../../../foo"),
ultest.WithFile("sj://user/dot-dot/../../foo"),
ultest.WithFile("sj://user/dot-dot/../foo"),
ultest.WithFile("sj://user//starts-slash"),
ultest.WithFile("sj://user/ends-slash"),
ultest.WithFile("sj://user/ends-slash/"),
ultest.WithFile("sj://user/ends-slash//"),
ultest.WithFile("sj://user/mid-slash//file"),
)
state.Succeed(t, "cp", "sj://user", "some/deep/folder", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "some/deep/folder/foo", Contents: "sj://user/dot-dot/../foo"},
ultest.File{Loc: "some/deep/folder/starts-slash", Contents: "sj://user//starts-slash"},
ultest.File{Loc: "some/deep/folder/ends-slash", Contents: "sj://user/ends-slash//"},
ultest.File{Loc: "some/deep/folder/mid-slash/file", Contents: "sj://user/mid-slash//file"},
)
})
t.Run("DirectoryConflict", func(t *testing.T) {
state := ultest.Setup(commands,
cmd/uplink: fix recursive copy and improve tests recursive copy had a bug with relative local paths. this fixes that bug and changes the test framework to use more of the code that actually runs in uplink and only mocks out the direct interaction with the operating system. Change-Id: I9da2a80bfda8f86a8d05879b87171f299f759c7e
2022-05-10 19:31:20 +01:00
ultest.WithFile("sj://user/filedir"),
ultest.WithFile("sj://user/filedir/file"),
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
)
state.Fail(t, "cp", "sj://user", "root", "--recursive").RequireLocalFiles(t,
cmd/uplink: fix recursive copy and improve tests recursive copy had a bug with relative local paths. this fixes that bug and changes the test framework to use more of the code that actually runs in uplink and only mocks out the direct interaction with the operating system. Change-Id: I9da2a80bfda8f86a8d05879b87171f299f759c7e
2022-05-10 19:31:20 +01:00
ultest.File{Loc: "root/filedir", Contents: "sj://user/filedir"},
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
)
})
t.Run("EmptyIntoEmpty", func(t *testing.T) {
state := ultest.Setup(commands,
ultest.WithFile("sj://user//"),
)
state.Fail(t, "cp", "sj://user", "", "--recursive")
})
t.Run("ExistingDirectory", func(t *testing.T) {
state := ultest.Setup(commands,
cmd/uplink: fix recursive copy and improve tests recursive copy had a bug with relative local paths. this fixes that bug and changes the test framework to use more of the code that actually runs in uplink and only mocks out the direct interaction with the operating system. Change-Id: I9da2a80bfda8f86a8d05879b87171f299f759c7e
2022-05-10 19:31:20 +01:00
ultest.WithFile("sj://user/filedir"),
ultest.WithFile("/home/user/filedir/file"),
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
)
state.Fail(t, "cp", "sj://user", "/home/user", "--recursive")
})
}
func TestCpRemoteToRemote(t *testing.T) {
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
state := ultest.Setup(commands,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.WithFile("sj://b1/dot-dot/../../../../../foo", "data1"),
ultest.WithFile("sj://b1/dot-dot/../../foo", "data2"),
ultest.WithFile("sj://b1/dot-dot/../foo", "data3"),
ultest.WithFile("sj://b1//starts-slash", "data4"),
ultest.WithFile("sj://b1/ends-slash", "data5"),
ultest.WithFile("sj://b1/ends-slash/", "data6"),
ultest.WithFile("sj://b1/ends-slash//", "data7"),
ultest.WithFile("sj://b1/mid-slash//file", "data8"),
ultest.WithBucket("b2"),
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
)
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("BucketToBucket", func(t *testing.T) {
state.Succeed(t, "cp", "sj://b1", "sj://b2", "--recursive").RequireFiles(t,
ultest.File{Loc: "sj://b1/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b1/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b1/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b1//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b1/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b1/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b1/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b1/mid-slash//file", Contents: "data8"},
ultest.File{Loc: "sj://b2/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b2/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b2/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b2//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b2/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b2/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b2/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b2/mid-slash//file", Contents: "data8"},
)
})
t.Run("BucketToPrefix", func(t *testing.T) {
state.Succeed(t, "cp", "sj://b1", "sj://b2/pre", "--recursive").RequireFiles(t,
ultest.File{Loc: "sj://b1/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b1/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b1/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b1//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b1/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b1/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b1/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b1/mid-slash//file", Contents: "data8"},
ultest.File{Loc: "sj://b2/pre/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b2/pre/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b2/pre/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b2/pre//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b2/pre/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b2/pre/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b2/pre/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b2/pre/mid-slash//file", Contents: "data8"},
)
})
t.Run("PrefixToBucket", func(t *testing.T) {
state.Succeed(t, "cp", "sj://b1/dot-dot", "sj://b2", "--recursive").RequireFiles(t,
ultest.File{Loc: "sj://b1/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b1/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b1/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b1//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b1/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b1/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b1/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b1/mid-slash//file", Contents: "data8"},
ultest.File{Loc: "sj://b2/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b2/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b2/dot-dot/../foo", Contents: "data3"},
)
})
t.Run("PrefixToPrefix", func(t *testing.T) {
state.Succeed(t, "cp", "sj://b1/dot-dot", "sj://b2/pre", "--recursive").RequireFiles(t,
ultest.File{Loc: "sj://b1/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b1/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b1/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b1//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b1/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b1/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b1/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b1/mid-slash//file", Contents: "data8"},
ultest.File{Loc: "sj://b2/pre/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b2/pre/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b2/pre/dot-dot/../foo", Contents: "data3"},
)
})
cmd/uplink: integrate server-side copy with uplink cp command Resolves https://github.com/storj/storj/issues/4486 Change-Id: I42ac2ad2e1a05df4a83606f1990b639f08791403
2022-03-15 10:07:19 +00:00
t.Run("ObjectToObject", func(t *testing.T) {
state.Succeed(t, "cp", "sj://b1/ends-slash", "sj://b1/ends-slash-copy").RequireFiles(t,
ultest.File{Loc: "sj://b1/dot-dot/../../../../../foo", Contents: "data1"},
ultest.File{Loc: "sj://b1/dot-dot/../../foo", Contents: "data2"},
ultest.File{Loc: "sj://b1/dot-dot/../foo", Contents: "data3"},
ultest.File{Loc: "sj://b1//starts-slash", Contents: "data4"},
ultest.File{Loc: "sj://b1/ends-slash", Contents: "data5"},
ultest.File{Loc: "sj://b1/ends-slash-copy", Contents: "data5"},
ultest.File{Loc: "sj://b1/ends-slash/", Contents: "data6"},
ultest.File{Loc: "sj://b1/ends-slash//", Contents: "data7"},
ultest.File{Loc: "sj://b1/mid-slash//file", Contents: "data8"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
}
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
func TestCpLocalToLocal(t *testing.T) {
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
state := ultest.Setup(commands,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.WithFile("/home/user1/folder1/file1.txt", "data1"),
ultest.WithFile("/home/user1/folder1/file2.txt", "data2"),
ultest.WithFile("/home/user1/folder2/file3.txt", "data3"),
ultest.WithFile("/home/user1/folder2/folder3/file4.txt", "data4"),
ultest.WithFile("/home/user1/folder2/folder3/file5.txt", "data4"),
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
)
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("FolderToFolder", func(t *testing.T) {
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
state.Fail(t, "cp", "/home/user1", "/home/user2", "--recursive").RequireFiles(t,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.File{Loc: "/home/user1/folder1/file1.txt", Contents: "data1"},
ultest.File{Loc: "/home/user1/folder1/file2.txt", Contents: "data2"},
ultest.File{Loc: "/home/user1/folder2/file3.txt", Contents: "data3"},
ultest.File{Loc: "/home/user1/folder2/folder3/file4.txt", Contents: "data4"},
ultest.File{Loc: "/home/user1/folder2/folder3/file5.txt", Contents: "data4"},
)
})
t.Run("FolderToEmpty", func(t *testing.T) {
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
state.Fail(t, "cp", "/home/user1", "", "--recursive").RequireFiles(t,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.File{Loc: "/home/user1/folder1/file1.txt", Contents: "data1"},
ultest.File{Loc: "/home/user1/folder1/file2.txt", Contents: "data2"},
ultest.File{Loc: "/home/user1/folder2/file3.txt", Contents: "data3"},
ultest.File{Loc: "/home/user1/folder2/folder3/file4.txt", Contents: "data4"},
ultest.File{Loc: "/home/user1/folder2/folder3/file5.txt", Contents: "data4"},
)
})
cmd/uplink: fix recursive copy and improve tests recursive copy had a bug with relative local paths. this fixes that bug and changes the test framework to use more of the code that actually runs in uplink and only mocks out the direct interaction with the operating system. Change-Id: I9da2a80bfda8f86a8d05879b87171f299f759c7e
2022-05-10 19:31:20 +01:00
t.Run("RootToFolder", func(t *testing.T) {
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
state.Fail(t, "cp", "/", "/pre", "--recursive").RequireFiles(t,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.File{Loc: "/home/user1/folder1/file1.txt", Contents: "data1"},
ultest.File{Loc: "/home/user1/folder1/file2.txt", Contents: "data2"},
ultest.File{Loc: "/home/user1/folder2/file3.txt", Contents: "data3"},
ultest.File{Loc: "/home/user1/folder2/folder3/file4.txt", Contents: "data4"},
ultest.File{Loc: "/home/user1/folder2/folder3/file5.txt", Contents: "data4"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
}
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
func TestCpTrailingSlashes(t *testing.T) {
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
state := ultest.Setup(commands,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.WithFile("sj://user/foo/"),
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
)
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("Single", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/foo/", "pre").RequireLocalFiles(t,
ultest.File{Loc: "pre", Contents: "sj://user/foo/"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("SingleIntoFolder", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/foo/", "pre/").RequireLocalFiles(t,
ultest.File{Loc: "pre/foo", Contents: "sj://user/foo/"},
)
})
t.Run("Recursive", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/", "pre", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "pre/foo", Contents: "sj://user/foo/"},
)
})
t.Run("RecursiveIntoFolder", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/", "pre/", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "pre/foo", Contents: "sj://user/foo/"},
)
})
t.Run("RecursiveOnFile", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/foo/", "pre", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "pre", Contents: "sj://user/foo/"},
)
})
t.Run("RecursiveOnFileIntoFolder", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/foo/", "pre/", "--recursive").RequireLocalFiles(t,
ultest.File{Loc: "pre", Contents: "sj://user/foo/"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
}
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
func TestCpStandard(t *testing.T) {
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
state := ultest.Setup(commands,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.WithFile("sj://user/foo"),
ultest.WithFile("/home/user/foo"),
cmd/uplink: fix recursive copy and improve tests recursive copy had a bug with relative local paths. this fixes that bug and changes the test framework to use more of the code that actually runs in uplink and only mocks out the direct interaction with the operating system. Change-Id: I9da2a80bfda8f86a8d05879b87171f299f759c7e
2022-05-10 19:31:20 +01:00
ultest.WithStdin("-"),
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
)
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("StdinToRemote", func(t *testing.T) {
state.Succeed(t, "cp", "-", "sj://user/bar").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/foo"},
ultest.File{Loc: "sj://user/bar", Contents: "-"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("StdinToRemoteTrailing", func(t *testing.T) {
state.Succeed(t, "cp", "-", "sj://user/bar/").RequireRemoteFiles(t,
ultest.File{Loc: "sj://user/foo"},
ultest.File{Loc: "sj://user/bar/", Contents: "-"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("StdinToLocal", func(t *testing.T) {
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
state.Fail(t, "cp", "-", "/home/user/bar").RequireLocalFiles(t,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.File{Loc: "/home/user/foo"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("StdinToLocalTrailing", func(t *testing.T) {
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
state.Fail(t, "cp", "-", "/home/user/bar/").RequireLocalFiles(t,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.File{Loc: "/home/user/foo"},
)
})
t.Run("RemoteToStdout", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/foo", "-").RequireFiles(t,
ultest.File{Loc: "sj://user/foo"},
ultest.File{Loc: "/home/user/foo"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
t.Run("LocalToStdout", func(t *testing.T) {
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
state.Fail(t, "cp", "/home/user/foo", "-").RequireFiles(t,
cmd/uplinkng: parallelsm and a ton of fixes this was just supposed to add parallel uploads/downloads and it does do that, but i then found a bunch of bugs with respect to path handling that i thought i had under control. oops. so this adds a ton of tests and tries to make the logic in ulloc to be more consistent. almost all of the actual file handling bits and knowledge happens in cmd_cp now where it should belong. additionally, the s3 command has the behavior that if your bucket has the file s3://bucket/file, then executing s3 ls s3://bucket/fi returns nothing. this change makes uplinkng match that behavior even if i don't personally like it. a big portion of the weirdness is the concept introduced that i've named "directoryish", which intends to capture the behavior that if a user copies a file to that location then the base name of the source should be appended on rather than a direct copy. this concept is entirely a based on the string value and not the actual filesystem state. hence, the cp command is responsible for checking if local paths are actually a directory, and adding a trailing slash if necessary to make them "directoryish". additionally, the empty key for a bucket and the empty string for local paths are considered "directoryish". Change-Id: I9120d18616fd813b29ff81beed4f5993caa99fb6
2021-06-25 02:55:13 +01:00
ultest.File{Loc: "sj://user/foo"},
ultest.File{Loc: "/home/user/foo"},
)
})
cmd/uplinkng: tests for cp this adds some stuff to ultest so that the set of files created by a test can be inspected after so that we can write some tests for the cp command to observe that it does what it is supposed to do. Change-Id: I98b8fb214058140dfbb117baa7acea6a2cc340e1
2021-05-12 17:16:56 +01:00
}
scripts: add 'uplink cp' tests for stdin/stdout Uplink can upload from stdin and download to stdout. We had such tests for old binary but now we were missing it. Change-Id: I5110a9f531f5cc21277fa53611995fb5b556ff16
2022-04-22 12:07:26 +01:00
func TestCpInputValidation(t *testing.T) {
state := ultest.Setup(commands)
state.Fail(t, "cp", "/home/user/file1.txt", "sj://testbucket/", "--parallelism-chunk-size", "-1")
}
cmd/uplink: improve cp behavior allow multiple source paths and a single destination path. this makes commands like `uplink cp foo* sj://bucket` work as expected. require at least one remote path when copying. this ensures that users don't accidentally overwrite their local files with other local files, which is almost never what they wanted because they would just use cp. Change-Id: I28948f4ff735d29db06de81fc8c2a15b9f4ee3f5
2022-09-26 17:21:45 +01:00
func TestCpMultipleSourcePaths(t *testing.T) {
state := ultest.Setup(commands,
ultest.WithFile("/home/user/file1.txt", "local1"),
ultest.WithFile("/home/user/file2.txt", "local2"),
ultest.WithFile("sj://user/file1.txt", "remote1"),
ultest.WithFile("sj://user/file2.txt", "remote2"),
)
t.Run("LocalToRemoteOverwrite", func(t *testing.T) {
state.Succeed(t, "cp", "/home/user/file1.txt", "/home/user/file2.txt", "sj://user").RequireFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local1"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "local2"},
ultest.File{Loc: "sj://user/file1.txt", Contents: "local1"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "local2"},
)
})
t.Run("LocalToRemoteDirectory", func(t *testing.T) {
state.Succeed(t, "cp", "/home/user/file1.txt", "/home/user/file2.txt", "sj://user/new").RequireFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local1"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "local2"},
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote1"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "remote2"},
ultest.File{Loc: "sj://user/new/file1.txt", Contents: "local1"},
ultest.File{Loc: "sj://user/new/file2.txt", Contents: "local2"},
)
})
t.Run("RemoteToLocalOverwrite", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/file1.txt", "sj://user/file2.txt", "/home/user").RequireFiles(t,
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote1"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "remote2"},
ultest.File{Loc: "/home/user/file1.txt", Contents: "remote1"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "remote2"},
)
})
t.Run("RemoteToLocalDirectory", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/file1.txt", "sj://user/file2.txt", "/home/user/new").RequireFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local1"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "local2"},
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote1"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "remote2"},
ultest.File{Loc: "/home/user/new/file1.txt", Contents: "remote1"},
ultest.File{Loc: "/home/user/new/file2.txt", Contents: "remote2"},
)
})
t.Run("MixedToRemoteDirectory", func(t *testing.T) {
state.Succeed(t, "cp", "sj://user/file1.txt", "/home/user/file2.txt", "sj://user/new").RequireFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local1"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "local2"},
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote1"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "remote2"},
ultest.File{Loc: "sj://user/new/file1.txt", Contents: "remote1"},
ultest.File{Loc: "sj://user/new/file2.txt", Contents: "local2"},
)
})
t.Run("MixedToLocalPartiallyFails", func(t *testing.T) {
state.Fail(t, "cp", "sj://user/file1.txt", "/home/user/file2.txt", "/home/user/new").RequireFiles(t,
ultest.File{Loc: "/home/user/file1.txt", Contents: "local1"},
ultest.File{Loc: "/home/user/file2.txt", Contents: "local2"},
ultest.File{Loc: "sj://user/file1.txt", Contents: "remote1"},
ultest.File{Loc: "sj://user/file2.txt", Contents: "remote2"},
ultest.File{Loc: "/home/user/new/file1.txt", Contents: "remote1"},
)
})
}
Reference in New Issue Copy Permalink