about copyparty-sfx.py

copyparty-sfx.py is an SFX (self-extracting archive).

why it exists

because copyparty is made to be as portable and flexible as possible, and because copyparty is really just a small and simple python module, there's many ways to obtain and run it depending on your circumstances:

• the PyPI package is quite optimal; the only drawback is you need to install the package somehow to run it, plus any optional dependencies you may want
• ...unless you have uv, then just uv tool run copyparty is nice
• your Linux distro may have a package, then you get the huge advantage that you automatically get updates, but (depending on distro) maybe slightly delayed
• copyparty.pyz, the zipapp, is the boring and standard way to distribute a collection of python modules as a single file. This format has drawbacks: Poor performance due to python stdlib limitations, and it strongly prefers bundled modules over systemwide ones, so can be less secure
• the windows exe files can be convenient, but has many drawbacks: Windows-only, universally hated by antivirus software (plagued by false-positives), and only has the bare-minimum of features that are built into the exe (not all features can be enabled/used)
• docker images are popular, but effectively Linux-only; the performance of containers on Windows/MacOS is too shit. And yes, this also includes WSL, since performance is obviously better when you run python directly on the OS. Plus, unless you're already using Docker/Podman for other stuff, then it's quite overkill for something as tiny and portable as copyparty

Which brings us to copyparty-sfx.py, in many ways the best option;

• the only thing you need to supply is python, which you probably already have, so just run python copyparty-sfx.py and you have a party
• it's a tiny package of just copyparty itself, plus some dependencies
• if you have a more recent version of a dependency, then it'll use your versions, so on Linux you automatically get updates from your OS package manager
• you can enable additional features by installing optional dependencies
• performance is optimal; no extra layers of complexity or bottlenecks between copyparty and your HDD, just speed
• it even runs on android (and, somewhat, iOS)

but maybe the wall of binary garbage in the file looks a bit funny, so:

how it works

There's a tiny bit of python-code at the start (the unpacker) followed by a completely normal tar.gz archive (basically a .zip file) which contains a few python modules; everything necessary to run copyparty. That is, everything except for a python installation, which you probably already have.

In other words, this is not a form of obfuscation, just efficient packaging. If you want to manually extract the archive without running the python code at all, here's how:

1. Delete everything up to and including the # eof line
2. Remove/discard all \n (byte 0x0a / linefeed)
3. Remove/discard the # at start of each line
4. Replace ?0 with \0 (byte 0x00 / nullbyte)
5. Replace ?n with \n (byte 0x0a / linefeed)
6. Replace ?r with \r (byte 0x0d / carriage-return)
7. Replace ?? with ? (byte 0x3f / questionmark)
8. Feed the file into tar -zvt or tar -zvx

Trivia: The reason for the quirky questionmark escaping is that python doesn't allow nullbytes in comments, and comments have a max-length on older versions.

And here's a simple awk script which does just that; taking copyparty-sfx.py as input, streaming out the tar.gz within, and listing (zvt) the contents of that archive (replace zvt with zvx to extract):

cat copyparty-sfx.py | LC_ALL=C gawk '
/^# eof$/{o=1;next}
o{for(a=2;a<=length($0);a++){
c=substr($0,a,1)
if(c!="?"){printf"%s",c;continue}
switch(substr($0,++a,1)){
case"0":c=0;break
case"r":c=13;break
case"n":c=10;break
default:c=63;break
}printf"%c",c}}' | tar -zvt

(and before someone tries to give me a UUoC award, it's there to make it obvious what's going on)

how it was made

the above explains how to extract copyparty-sfx.py as the simple tar.gz that it is, but if you want to know how it was made, then docs/devnotes.md tells the whole story, starting from the completely normal source code in the git-repo (to the extent that we can call any of it "completely normal")

// todo

there's more info and better explanations in github issues #270 and #345 which haven't been added here yet