Split large file

Whatever you set in chunkSize, in bytes, which defaults to 1048576, that is 1 MiB. It must be a whole number of 1 or more. Every part is exactly that size except the last one, which holds the remainder. The split is a plain byte cut, so it works on any file type.

Your whole file name with .partNNN appended, so backup.zip becomes backup.zip.part001, backup.zip.part002 and so on. The counter is padded to at least three digits, more when the part count needs it, so the files sort correctly. This is not the naming the Unix split command uses.

With Join split files, which is built for this naming. It sorts the parts numerically, checks for a gap at the start or in the middle, and writes one file named from the shared base. Concatenating the parts in order with any other tool works too, since the split adds no headers or padding.

No. The parts are exact byte slices of the original with nothing added, so joining them back gives you a file identical to what you started with. Check that with Checksum verify if you want proof: hash the original before splitting and the joined file afterwards.

Because there are zero bytes to cut. An empty file is refused with "file is empty, nothing to split" rather than producing a single empty part that would look like a result. A file smaller than the chunk size is fine, and simply comes back as a single part.

No, and that is the awkward part. The whole file is read into memory before it is cut, and every part is held in memory too, so this cannot rescue a file your tab cannot already hold. Nothing is uploaded, so the ceiling is your own device.