TTarArchive - Extract with rights permissions

[RDL]

Hey 

How to extract a tar archive while maintaining file permissions?

Code: Pascal  [Select][+][-]

1. TarStream:=TTarArchive.Create(TarStream);
2. TarStream.Reset;
3. ClearDirRec(TarStreamDirRec);
4. while TarStream.FindNext(TarStreamDirRec) do begin
5.    if ForceDirectories('/tmp/'+ExtractFilePath(TarStreamDirRec.Name))=True then
6.       TarStream.ReadFile('/tmp/'+TarStreamDirRec.Name);
7. end;
8. TarStream.Free;
9.  

The code above extracts the files, but the permissions do not match those in the archive.

[RDL]

I made an analogue of the PermissionString function from libtar, so that the function would return the TMode code.

Code: Pascal  [Select][+][-]

1. uses
2.   BaseUnix
3.  

Code: Pascal  [Select][+][-]

1. function PermissionCode(Permissions : TTarPermissions): TMode;
2. begin
3. Result:=&0;
4. if tpReadByOwner in Permissions then Result:=Result+&400;
5. if tpWriteByOwner in Permissions then Result:=Result+&200;
6. if tpExecuteByOwner in Permissions then Result:=Result+&100;
7. if tpReadByGroup in Permissions then Result:=Result+&40;
8. if tpWriteByGroup in Permissions then Result:=Result+&20;
9. if tpExecuteByGroup in Permissions then Result:=Result+&10;
10. if tpReadByOther in Permissions then Result:=Result+&4;
11. if tpWriteByOther in Permissions then Result:=Result+&2;
12. if tpExecuteByOther in Permissions then Result:=Result+&1;
13. end;
14.  

Next, just assign permissions with fpChmod

Code: Pascal  [Select][+][-]

1. fpChmod('/tmp/'+TarStreamDirRec.Name,PermissionCode(TarStreamDirRec.Permissions));
2.  

This works, but perhaps there is an easier way to solve this problem.

I've pasted the example:
Unpack test_archive.tar archive with tar archiver and you will see that the unpacked file has rwxr-xr-x permissions
Unzip the archive test_archive.tar using the application and you will see that the unpacked file has the rights rw-r--r--
Uncomment line 39 in the example source code and compile the application. After that, the unpacked file will have the same rights as in the archive.

[MarkMLl]

I've not used it, but is the mismatch caused by the current umask value? I think you could usefully give examples of the values you expect and are seeing, and an example program and test file.

MarkMLl

[RDL]

@MarkMLl
Yes, I have attached an example in my post above.

[MarkMLl]

umask is 0022, unpacking using GNU tar I see -rwxr-xr-x while using your test program I see -rw-r--r-- i.e. the x modes have been stripped.

My suspicion is that this is for compatibility with pre-GNU tar (by analogy, FTP would always strip the x mode) in order to reduce the likelihood that something sneaked an executable onto the system unexpectedly. I don't, unfortunately, have a suitable system (i.e. SunOS/Solaris etc.) up and running to test this.

...although I have to add that minimal perusal of the source doesn't show anything to back that speculation up. I don't have time to start stepping through it, and in any case I'm not convinced that it's "wrong behaviour".

...in fact is that library actually trying to set ownership and mode at all, or just accepting that it's operating on behalf of the current user and using the current defaults? This is complicated slightly by the fact that the  file  command shows that archives written by the library are "POSIX" format rather than the more recent "POSIX (Gnu)", where the latter (e.g.) saves user/group by name rather than number.

MarkMLl

[RDL]

@MarkMLl
That's why I wrote the PermissionCode function that reads the permissions and at first glance it works as it should.
There may be a way to do this without an additional function, but I don't know about it. That's why I turned to you. 

[MarkMLl]

That's why I wrote the PermissionCode function that reads the permissions and at first glance it works as it should.
There may be a way to do this without an additional function, but I don't know about it. That's why I turned to you. 

Or rather, turned to the community: I'd hardly call myself the local expert :-)

I suspect that the whole area of setting permissions/modes (plus of course user/group ownership) is sufficiently OS-specific that it was left out of (or removed from) the library intentionally. I'm a little surprised that the author went to the trouble of breaking out the various mode bits if he wasn't going to use them, but it might be that he realised that he was letting himself in for a big (and controversial) job.

My suggestion would be to stick with your PermissionCode() function, but to do a lot of careful error checking inside it since- if your program lives long and prospers- you might easily encounter a situation where one or more platforms decides that e.g. an ordinary user can't set the group execute bit.

Finally, I'm a little concerned that that author of the library appears to have used it as an excuse to show off his prowess in OO programming, stream handling etc. when a much simpler approach would have sufficed. Mark Roth's original libtar is 375+305 lines (.c and .h files respectively), Fuzix tar to run on an RP2040 is 744, while this is 995 lines and arguably incomplete. It would be all very well if it provided e.g. indexing facilities so that once the archive had been read an individual file could be extracted efficiently, but all I see here is "OO is sexy and we should use it at every possible opportunity"... in English we'd call that "willy waving" but I appreciate that what you see might be at Google's discretion :-)

MarkMLl