.tar doesn't support files of size above 8gb

[aurangzaib.danial]

I have my personal hfs server up and running and my friends download my shared games through it. Now the problem is some folders contain files sizing above 8 gb and now if some one tries to archive the entire folder, it will get downloaded but won't open and will be corrupted. I guess it is happening because tar doesn't support files above 8 gb and results in total denial. For fixing this, I always have to split up a large file so then my friends can download. Splitting the files up takes too much time and its kind of irritating and not convenient. But I have read on internet that there are fix available now, to remove the 8 gb restriction on tar files. I hope rejetto removes such restriction, otherwise HFS is great !

[bmartino1]

http://www.wikihow.com/Compress-Large-Files

It depends on what the file is, i assume you are using a "iso / disk image"

for it being a 8 GB game...

i'm not aware of the tar feature in HFS having a limit, if so, "f6" edit the template and rase the number.... look for tar

other wise, zip compress it you self, i would recommend winrar: http://www.rarlab.com/download.htm

[aurangzaib.danial]

Thank you for your reply, the thing is, iso of games are above 8 gb these days and popular games are more of 50 to 60 gb iso as well. Now compression in case of a 60 gb iso would take a lot of time to be frank while splitting the files through some rar program like winrar, also takes time. Despite of iso, not all games are in the form of iso, there are .bin files which are mostly above 10 gb e.g. GTA V bin file is almost 50 gb ! The better way would be to remove the restrictions of a tar archive. I have mentioned some of the default restrictions of tar which is being used in hfs as folder archive below ...

1: The maximum length of a file name is limited to 256 characters, provided that the file name can be split at a directory separator in two parts, first of them being at most 155 bytes long. So, in most cases the maximum file name length will be shorter than 256 characters.
2: The maximum length of a symbolic link name is limited to 100 characters.
3: Maximum size of a file the archive is able to accommodate is 8GB
4: Maximum value of UID/GID is 2097151.
5: Maximum number of bits in device major and minor numbers is 21.

Referring to point 3, explains that such restriction is default so there is nothing to edit in the html template of hfs. Any other solution would be much appreciated !

[bmartino1]

agreed, but that is the max of my knowledge with FHS, splinting the files would be better.

but not every one has a program to put the splits together (and that is time consuming_ and haven't tested hfs with setting like that.

A more experienced user will need to help you here.

[aurangzaib.danial]

Thank you for your reply, waiting for a solution as it would save me a lot of time and might be helpful for others as well !

[rejetto]

i just had a look at the encoding of filesize in TAR, and it uses 12 octal digits, it means 8^12=68GB.
Are you sure it's the TAR corrupted, and not the program you use to open it that isn't able to handle it?
what softwares did you use for your tests?

[aurangzaib.danial]

First of all, I am really grateful that administrator replied. Secondly, I used Winrar and 7zip, I tested by making number of archives from hfs but still the archive always gets corrupted if it contains any file of size above 8gb. I recommend archiving a folder with files above 8gb and then try to extract them. Thank you !

[bitingsock]

I am experiencing this as well. To reiterate: if a single file that is being included is over 8gb it causes a problem.
Another issue is that while HFS serves such a large file in TAR it freezes the HFS ui

[Rapid]

i just had a look at the encoding of filesize in TAR, and it uses 12 octal digits, it means 8^12=68GB.
Are you sure it's the TAR corrupted, and not the program you use to open it that isn't able to handle it?
what softwares did you use for your tests?

According ustar specification for TAR - there is only 11 octal digits for size + 1 space = 8GB
But most programs should support POSIX specification for TAR, that uses binary size and therefore can easily save Int64 size.
Please have a look: https://github.com/drapid/rnq/blob/aaac45aae47ed632e17c5dae129bff713baea7eb/for.RnQ/RnQNet.Uploads.pas#L731
I'm not sure that I've made ALL necessary changes though...