v467: File Tool > Split Function: problems with large files

redseujac

Version 1.8.0.467 gives issues again with the File-Split function with large files.

I dragged and dropped 2 Acronis True Image *.tib files with sizes of 5 GB and 9 GB to the File Tool .

When I select a file and go to "More functions" and click "Split", I get each time the following message:

: Failed to access "...Filename..."

: No valid input file found

So the tool is even not able to access the large file :

jv16

Can someone else confirm this issue? Does the problem also occur with other kinds of large files? (other than Acronis True Image)

delphi

jv16 wrote
Can someone else confirm this issue?

Yes

jv16 wrote
Does the problem also occur with other kinds of large files? (other than Acronis True Image)

Images of DVDs (when their size is over 4 GB).

jv16

This problem has now been fixed, thank you for reporting! The next released version containing the fix will be released in later this week.

redseujac

Anselmo should thank jv16 here for that fix :

anselmo

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

redseujac

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

redseujac

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

jv16

The remaining issues should now be fixed, thank you for reporting!

layman

jv16 wrote
The remaining issues should now be fixed, thank you for reporting!

In version 468, the filesplit function still does not work on files >4GB. The program still manifests the same symptoms. Observed with filmon, the program goes into a loop opening and closing the directory and never produces output.

Also, the custom size function is not terribly useful in its present form because it won't accept fractional values. For example, you can specify a 4GB split, but not 4.3GB.

Anyone who has been looking for a splitter that works for very large files knows it's not easy to find one. I've been using a program that has vanished from the Web, but I recently discovered that PeaZip has a split tool that does the job nicely.

jv16

layman wrote
jv16 wroteThe remaining issues should now be fixed, thank you for reporting!

In version 468, the filesplit function still does not work on files >4GB. The program still manifests the same symptoms. Observed with filmon, the program goes into a loop opening and closing the directory and never produces output.

I know, in the message I was referring to the next released version. It should work perfectly even with large files. The next version will be released probably in next week.

jv16

jv16 wrote

I know, in the message I was referring to the next released version. It should work perfectly even with large files. The next version will be released probably in next week.

The new version that should fix this problem was actually just released, I didn't see any reason for waiting to next week. The new version also contains improved debug log feature that now creates two different debug logs.

layman

jv16 wrote
The new version that should fix this problem was actually just released, I didn't see any reason for waiting to next week. The new version also contains improved debug log feature that now creates two different debug logs.

v472 does, indeed, correct the problem with large files. I did a trial split and rejoin with a 10Gb Acronis image file, and the result satisfied a byte-for-byte comparison with the original.

While the basic function now appears to be working correctly, the usability flaws of the feature still remain. For one thing, it insists upon placing the output of a "merge" in the same directory as the first of the input segments (the user can exert no control over where output is placed.) Also, as mentioned in a previous post, the user can enter only integer values as a chunk size, so it isn't possible to specify (for example) a 4.3 Gb chunk. That's not an insurmountable limitation, but it is an inconvenience.

jv16

layman wrote

While the basic function now appears to be working correctly, the usability flaws of the feature still remain. For one thing, it insists upon placing the output of a "merge" in the same directory as the first of the input segments (the user can exert no control over where output is placed.) Also, as mentioned in a previous post, the user can enter only integer values as a chunk size, so it isn't possible to specify (for example) a 4.3 Gb chunk. That's not an insurmountable limitation, but it is an inconvenience.

Thank you for verifying this problem is finally fixed, I must tell you that fixing this puppy was some long battle. There were just tons of functions that needed to be changed in order to add the support for large files.

As for the output directory, you can define that under the File Split tool's Options tab. You are correct about the integer values though, this restriction was made in order to simplify the code. But if you want to split files to 4.3 Gb chunks, you can simply define the chunk size to 4617089843 bytes, which is roughly 4.3 Gb (if I did the math right, which I always doubt).

layman

jv16 wrote
As for the output directory, you can define that under the File Split tool's Options tab.

Better test this yourself. There is no options tab (or any other tab, for that matter) when you select the "merge" function. There is just a dialogue box for the output file name -- and the program ignores any disk designation entered, prepending its own.

jv16

layman wrote
jv16 wroteAs for the output directory, you can define that under the File Split tool's Options tab.

Better test this yourself. There is no options tab (or any other tab, for that matter) when you select the "merge" function. There is just a dialogue box for the output file name -- and the program ignores any disk designation entered, prepending its own.

Oh sorry, I thought you ment the File Split feature, not the merge feature. You are correct, the Merge always adds the new file to the same directory where the input files are.

tullik

The Merge feature pop-up has these characteristics:

1. The entry pop-up is prefilled with the original file's name.

2. After you click OK, the program always prefixes the path of the topmost file chunk in the list, whether you want it to, or not.

3. Before clicking OK, you can change the file name.

4. You can also prefix a subfolder, which must already exist, of the folder of the topmost file chunk.

5. Except for the above, you cannot tell the program to put the merged file anywhere else.

Incidentally, if you split the original file into ten or more chunks, you cannot arrange their names in the File tool list in the proper order for the merge, without some preliminary work. You have to manually rename the file chunks so they will sort in the correct order in the list.

These are more idiosyncrasies than bugs, unless jv16 decides otherwise. :)