anantlabs / tar-cs Goto Github PK

Thanks for creating the TAR library.  You have saved me some time.

There are some incompatibilities with your source and .NET 2.0.  You might want 
to update the Project Home to specific .NET 3.5 or higher or remove the 3.5+ 
features.  The items I had to change in your source to compile in 2.0.

(*) remove all var variable type declarations and replace with true class types
(*) remove short cuts for private class variable declaration with the <type> 
<prop name> { get; set; } pattern
(*) remove the short cut property initializer pattern such as var obj1 = new 
<type() { prop1 = v1, prop2 = v2, etc }

In the function
TarHeader.UpdateHeaderFromBytes()
are some converts to int calls. 

Some buffer reads are with ".Trim()" some don't.

I have a tar file that crashed the determination of SizeInBytes:
if((buffer[124] & 0x80) == 0x80) // if size in binary
{
  long sizeBigEndian = BitConverter.ToInt64(buffer,0x80);
  SizeInBytes = IPAddress.NetworkToHostOrder(sizeBigEndian);
}
else
{
  SizeInBytes = Convert.ToInt64(Encoding.ASCII.GetString(buffer, 124, 11), 8);
}

In the call of Convert.ToInt64 in the else section. I've added the ".trim" 
after the GetString-Method and it works. The result of extrat is similar the 
the extracting with 7zip.

Reading from a broken tar archive, the Read method in TarReader.cs keep looping 
endlesly...

The following couple of lines in  protected int Read(out byte[] buffer) makes 
sure I don't get stuck.

I have attached my version of TarReader.

if (inStream.Position == inStream.Length)
{
   buffer = null;
   throw new TarException("Inconsistency reading from tar, end of stream reached before all bytes consumed according to header");
}           }

What steps will reproduce the problem?
1. Created a tar archive of a directory with some files in it using 7-zip 9.20.
2. Tried to read it using the TarReader class, but a FormatException is thrown 
when reader.MoveNext(true) is called; more specifically, the expception is 
thrown in one of the calls to Convert.ToInt64 in the 
TarHeader.UpdateHeaderFromBytes method.

What is the expected output? What do you see instead?
FormatException is thrown while parsing the header of a valid tar file - the 
expected behaviour is to read the file without problems.

What version of the product are you using? On what operating system?
rev58 from SVN

Please provide any additional information below.
The problem the same as issue 6, whitespace can be present in the size, unix 
timestamp and checksum fields. Adding ".Trim()" to the string that will be 
converted by Convert.ToInt32/ToInt64 calls in the UpdateHeaderFromBytes() 
method solves the issue.

What steps will reproduce the problem?
1. TarWriter.Write should add all the corresponding directories
2. TarWriter must have a method that allows to add empty directory

What steps will reproduce the problem?
1. if I extract this file, the code is getting break.
2. I found this archive file has has the long name(filename is 127), this 
is not handled.
3. Can you suggest how to handle ? 
4. Problem path: 
./campsite/implementation/site/install/sample_templates/campsite_3.0-
sample-template-01-v1/templates

What is the expected output? What do you see instead?
need to extract this 
folder(./campsite/implementation/site/install/sample_templates/campsite_3.0
-sample-template-01-v1/templates) content.

What version of the product are you using? On what operating system?
latest version from SVN.

Please provide any additional information below.

What steps will reproduce the problem?
1. tar -cvzf 1.tar directoryNameWithChildDirectories
2. tarReader.ReadToEnd
3. crash

What is the expected output? What do you see instead?

extracted files

TarWriter should not write USTAR, because 
it is not retro compatible in most applications 
(event if the documentations says it is) 

i shall be sending a huge set of corrections / improvements soon, 

What steps will reproduce the problem?
1. Using an tar archive that ends with only one zero-filled records
2. The archive is created using Total Commander
3.

What is the expected output? What do you see instead?
Expected output is normal processing of tar archive. Instead the TarReader
reports "Broken archive".

What version of the product are you using? On what operating system?
0.92. Windows XP.

Please provide any additional information below.
Add condition "|| headerRead == 0" for the "return false" in MoveNext method. 

What steps will reproduce the problem?
1.
FileStream fStream = File.OpenWrite("TarArchive.tar");
tar_cs.TarWriter TAR = new tar_cs.TarWriter(fStream);
FileStream fStream2 = File.OpenRead("UserImages.bmp");
TAR.Write(fStream2);
TAR.Close();

What is the expected output? What do you see instead?

A working TAR archive is expected.
A broken TAR archive is produced (tried opening it with 7Zip as an 
example). 

When using a small XML or textfile a working TAR archive is produced.

What version of the product are you using? On what operating system?

0.92 on Windows XP

What steps will reproduce the problem?
1. Opened a tar.gz file

What is the expected output? What do you see instead?
Expected output is for the application to select the next file (regardless of 
the output).

What version of the product are you using? On what operating system?
WinXP x64
tar-cs-bin_0.92.tar.gz 

Please provide any additional information below.

System.FormatException was unhandled
  Message=Could not find any recognizable digits.
  Source=mscorlib
  StackTrace:
       at System.ParseNumbers.StringToInt(String s, Int32 radix, Int32 flags, Int32* currPos)
       at System.Convert.ToInt32(String value, Int32 fromBase)
       at tar_cs.TarHeader.UpdateHeaderFromBytes()
       at tar_cs.UsTarHeader.UpdateHeaderFromBytes()
       at tar_cs.TarReader.MoveNext(Boolean skipData)
       at XML_Analyzer.Summary.button1_Click(Object sender, EventArgs e) in C:\Users\ophirb\AppData\Local\Temporary Projects\XML_Analyzer\Summary.cs:line 276
       at System.Windows.Forms.Control.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnClick(EventArgs e)
       at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
       at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
       at System.Windows.Forms.Control.WndProc(Message& m)
       at System.Windows.Forms.ButtonBase.WndProc(Message& m)
       at System.Windows.Forms.Button.WndProc(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
       at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
       at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
       at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
       at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
       at System.Windows.Forms.Application.Run(Form mainForm)
       at XML_Analyzer.Program.Main() in C:\Users\ophirb\AppData\Local\Temporary Projects\XML_Analyzer\Program.cs:line 20
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

What steps will reproduce the problem?
1. Reading GZipStream as input stream
2. Running in debug mode
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
0.92

Please provide any additional information below.

add line "if (inStream.CanSeek)" before every "Debug.WriteLine("tar stream
position MoveNext in: " + inStream.Position);"

According to the specifaction

http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current

modification time (mtime) must be an octal number of seconds since epoch.

The existing code does not convert the difference to octal number.

I am using the sample code given on the documentation page

 private void Abc()
        {
            using (var outFile = File.Create("myOutFile.tar.gz"))
            {
                using (var outStream = new System.IO.Compression.GZipStream(outFile, System.IO.Compression.CompressionMode.Compress ))
                {
                    using (var writer = new TarWriter(outStream))
                    {
                        writer.ReadOnZero = true;
                        writer.Write("test22.txt");
                    }
                }
            }
        }

It generates the tar and gzip file without reporting any errors, but when I use 
7-Zip to open the gzip, it gives me the .tar file. but when i try to open the 
tar file using 7Zip, it gives me an error "Cannot open file 
c:\....\myOutFile.tar as archive.

Any help would be appreciated.

What steps will reproduce the problem?
1. A stream Read operation will return 0 if the End-Of-Stream has been reached, 
or any number less than or equal to the requested length if the read was 
successful.
2. Create a TarReader that reads from a stream that does not return the full 
block requested, but only partial reads.
3. The TarReader croaks, stating that the file format is invalid

0.92

What steps will reproduce the problem?
1. Create an tar archive
2. Open the tar archive using 7zip
3. Add an additional file to the archive)
4. Read the archive using tar-cs

What is the expected output? What do you see instead?
Expected: Read the archive
Instead: Exception in 'UpdateHeaderFromBytes', 'Mode = 
Convert.ToInt32(Encoding.ASCII.GetString(buffer, 100, 7)', reason: buffer 
content contains whitespaces at beginning and end. 


What version of the product are you using? On what operating system?


Please provide any additional information below.

I found some information about whitespaces: 'POSIX requires numeric fields to 
be zero-padded in the front, and allows them to be terminated with either space 
or NUL characters.' 
(http://people.freebsd.org/~kientzle/libarchive/man/tar.5.txt)
As far as I understood from the various documentation on the tar file format, 
numeric fields may contain whitespaces for padding in numeric fields.

Fixed this problem the following way:
Mode = Convert.ToInt32(Encoding.ASCII.GetString(buffer, 100, 7).TrimStart(' 
').TrimEnd(' '), 8);
            UserId = Convert.ToInt32(Encoding.ASCII.GetString(buffer, 108, 7).TrimStart(' ').TrimEnd(' '), 8);
            GroupId = Convert.ToInt32(Encoding.ASCII.GetString(buffer, 116, 7).TrimStart(' ').TrimEnd(' '), 8);

According to the specification

http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current

Modification time (mtime) is computed as number of seconds since epoch taken as 
UTC time.

If a user passes a UTC datetime value the result TAR file will be invalid, 
since the TarHeader class computes timestamp as difference between TheEpoch 
constant taken as local time.

It is suggested to create TheEpoch constant with explicit choice of UTC date 
time:

DateTime TheEpoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

And it is also necessary to compute the difference appropriately:

long ts = (long) (LastModification.ToUniversalTime() - TheEpoch).TotalSeconds;

in the TarHeader.LastModificationString property.

What steps will reproduce the problem?
As can be seen in the constructor of `TarHeader`, the UserId, GroupId and Mode 
are hardcoded to respectively: 101, 101 and 0777.

What is the expected output? What do you see instead?
using the UserId, GroupId and Mode of each file.

What version of the product are you using? On what operating system?
0.92, Win7

Please provide any additional information below.
In the best case, the implementation used to retrieve the UserId, the GroupId 
and the Mode of each file should work on both Windows & Linux (using Mono).

hi,

    it seems that it could not compress files? only storage the files?

Hi, I noticed that a memory profile indicates the function TarHeader.AddChars() 
is creating too many allocations.  A new string is being created for each 
character added.

This function may be removed because there is a built-in .NET string function 
that does the same:  String.PadLeft() or String.PadRight().

http://msdn.microsoft.com/en-us/library/92h5dc07.aspx

What steps will reproduce the problem?
Encoding.ASCII.GetString(buffer, 100, 7) can result in a string with a 
trailing space character. This will result in an error.

Solution:
Add a .Trim() command at the end of the Encoding like in the example below.

Mode = Convert.ToInt32(Encoding.ASCII.GetString(buffer, 100, 7).Trim(), 8);
UserId = Convert.ToInt32(Encoding.ASCII.GetString(buffer, 108, 7).Trim(), 
8);
GroupId = Convert.ToInt32(Encoding.ASCII.GetString(buffer, 116, 7).Trim(), 
8);

What version of the product are you using? On what operating system?
Latest CVN version

Please provide any additional information below.

Creating very big files works perfect now.

What steps will reproduce the problem?
1. Space and null characters can occur in Mode, UserId and GroupId header
strings 
2. Their conversion causes format exceptions while converting to int

What is the expected output? What do you see instead?
Expected output are properly converted header fields. Insted we get an
exception in Convert.ToInt32 function.

What version of the product are you using? On what operating system?
0.92

Please provide any additional information below.

Fixed a issue with too long file names.  

What steps will reproduce the problem?
1. please see archive.  I made it with 7zip. I have used framework 4.

Simple resolution:
In TarHeader.cs in UpdateHeaderFromBytes() I've added more Trim()s for string 
sent to Convert.To---().

This is an enhancement issue:
I will need in near future FAST tar unpacker - so I can contribute to this
project and implemet the indexing future (only for reading in the begining)

It is the .TMI file which is created normaly using ‘--index-file=file’
switch. It is wery usefull when you have a lot of small files in one tar
and need to unpack only some of them. (for example map atlas for TrekBuddy)

If you are interested, can you add me as contributor on this project,
vasiltsov?

I forked the code to fix the problem with extracting tar files using ReadToEnd. 
 Here's the code change at line 43 of tarreader.cs, which was a matter of 
rewriting the ReadToEnd method:

        public void ReadToEnd(string destDirectory)
        {
            while (MoveNext(false))
            {
                string totalPath = destDirectory + Path.DirectorySeparatorChar + FileInfo.FileName;
                string fileName = Path.GetFileName(totalPath);
                string directory = string.Empty;
                if (fileName.Length > 0)
                {
                    //directory = totalPath.Remove(totalPath.Length - fileName.Length);
                    using (FileStream file = File.Create(totalPath))
                    {
                        Read(file);
                    }
                }
                else
                {
                    directory = totalPath;
                    Directory.CreateDirectory(directory);
                }
            }
        }



I've also attached the modded file. Now it works! Just recompile with the 
attached change

The long file name in the archive has been handled.
Please find the attached patch. please provide feedback on this fix.