This module comes with some usefull functions to handle sfv files, and associated files (diz, zip, etc).
When a SFV file is uploaded, server will create .missing files.
If the file is corrupted, a .bad file will be created.
HINT: when uploading dirs, be sure to upload the SFV file first. The server will automatically check files as they are uploaded, and update a progress bar to quickly see how many percent are done.
NOTE to w_nd0ws users: although a (stupid) os can give you bad habits, files ARE CASE SENSITIVE !
A SFV file is a small verification file added to dirs, that stores records about a file or group of files integrity. When you compare a SFV file to a group of rar files it will check those rar files and tell you if they are complete or if they are "broken".
This is done by calculating a 32-bits checksum (*nix users already know md5 sums, this is similar - with a different algorithm).
The following parameters are available, you can set them in the config file (don't forget the prefix param_).
sfv_progressmeter
This dir is created during the upload, when the release isn't complete, to indicate the progression.
sfv_del_progressmeter
This regex must match the progressmeter, and is used to find and delete it when the number of files has changed.
sfv_incomplete_indicator
This will be a simlink created to indicate that the release isn't complete.
sfv_other_completebar
This dir will be created when release is complete.
e.g:
param_sfv_progressmeter = [WzD] - %3d%% Complete - [WzD]
When a SFV file is uploaded, an empty file is created for each name present in the SFV file, with '.missing' appended.
If a SFV file is present, each file uploaded (and present in sfv) is checked, and marqued as bad if checksums doesn't match (.missing are removed).
A lnts
Users/Groups definitions are stored in a plaintext file (though passwords
are encoded using unix crypt function).
You can edit the file "users", either being offline or reloading backend (without commiting it !) after. You should pay attention to the fact that this file should be edited carefully, and will be overwritten next time backend is commited.