Description of problem: useage of hjsplit(linux version) causes mate to get pegged at 100% cpu use, therby locking up the Xorg session when trying to split large files. Version-Release number of selected component (if applicable): detected in 22 How reproducible: always on use Steps to Reproduce: 1.possess hjsplit 2.use it to split a large file [such a case used to put the splits on another volume] Actual results: lockup central. ALthough Xorg is locked up, console access still works. disk activity remains(motherboard led), but to what extent? I only got a nearly 2GB file as output after some hours. looking into lxsplit as a result of this. TRUE: split can do the job, but can it put files on another volume? hjsplit CAN. Trying to work around a zip issue. Expected results: this should not happen
Latest version is from 2010 and does not start here, so i can't reproduce it. Also it isn't a fedora package. Why not using lxsplit commandline tool which is in repos. This works out of box with very low cpu usage. So i guess it's a UI proplem with that old program itself.
gtk-splitter is a small gui prog from repos where you can choose a output dir on another volume, and it works here.
Yeah, I would have thought so too. lxsplit doesnt do the job neither. Were all braindead noobs apparently.F* the UI. As a gee whiz I found someone else disqus page documenting the use of split and gzip(well I zip for now but anyways) and the following occurred: HMMMMM...... <input file> <output location> split apparently doesnt care where these files are located, contrary to the assumption. This feature needs to be documented. Split itself is doing what I want. I was using it wrong. from another volume(in my case an open ciphershed container): split -b 22500m backup.zip /home/<username>/backup/backup.zip.part- apparently works nicely.