Sick-Beard
Sick-Beard copied to clipboard
midgetspy
added support for hard-linking files instead of copying them on posix systems
Hi,
On POSIX systems (Linux/OS X), files can be hard-linked instead of copied, if they reside on the same filesystem. This means there will be two file entries pointing to the same data block. There are two major advantages to using hard-linking when possible: first, the operation is much faster (especially for big files), because only a new file entry is created, no data copy takes place; second, a lot less disk space will be used because both files share the same data. This should help when handling many TV shows with HD episodes :).
I've added a method linkOrCopyFile to helpers.py, which attempts to create a hard-link instead of a file copy; if the operation fails (e.g. the source and destination are on different file systems), an exception is raised and it falls back on the regular copyFile. I've also replaced all calls to copyFile with linkOrCopyFile in postProcessor.py, image_cache.py and helpers.py. I've tested it a bit, and it works as expected both when linking is possible and when not; however I only have a Linux machine to test it.
Cheers, -pwr
is your os really not that smart to know that your moving a file from point a to point b that it doesnt just moves the pointer?
thezoggy isn't trolling!
Unless KEEP_PROCESSED_DIR is set it moves the file... Or when the destination is on different mounting point, the python move function will copy/delete...
[code] # move the episode and associated files to the show dir if sickbeard.KEEP_PROCESSED_DIR: self._copy(self.file_path, dest_path, new_base_name, sickbeard.MOVE_ASSOCIATED_FILES) else: self._move(self.file_path, dest_path, new_base_name, sickbeard.MOVE_ASSOCIATED_FILES) [/code]
The files might be under some other program's management (e.g. torrent downloader), with its own policy of removing files (e.g. when reaching a certain share limit). Moving the files from the source folder will certainly confuse it and maybe even cause it to re-download the files. If the user chooses to move the files in SB, this will not impact in any way. If the user chooses to copy them, hard-linking instead of copying (when possible) will certainly be faster and conserve disk space.
He isn't trolling and I endorse pulling this into the main code.
If you use bittorrent to download the files and you want to keep seeding them, as of now the options offered by Sickbeard are
- Move them to your final folder, causing the bittorrent client to complain that the files are missing or, worse, redownload them
- Copy them, taking up space with duplicates.
I hope this will go in the main code soon. In the meantime, I'll patch my own code myself
I too forked Sick-Beard to use hard links, but if it's pulled into the main code it will be one less thing for me to maintain.
+1
How about using a symlink instead, for us people that has a separate download disk.
