ZipFileEncoder does not properly set unixPermissions

[alextekartik]

Hi and thanks for the package. In my usage, I was zipping a folder with an executable and I noticed the unixPermissions was not properly set (always null) when using ZipFileEncoder and the executable permission was lost.

The issue can be seen in the following unit tests (maybe something simpler could be found but this is a real usage scenario I'm using - tested on Linux but I guess it is wrong also on MacOS):

import 'dart:io';
import 'package:archive/archive_io.dart';
import 'package:test/test.dart';
import 'package:path/path.dart';

void main() {
  test('zip_executable', () async {
    // Only tested on linux so far
    if (Platform.isLinux) {
      var path = join('.dart_tool', 'archive', 'test', 'zip_executable');
      var srcPath = join(path, 'src');

      try {
        await Directory(path).deleteSync(recursive: true);
      } catch (_) {}
      await Directory(srcPath).create(recursive: true);

      // Create an executable file and zip it
      var file = File(join(srcPath, 'test.bin'));
      await file.writeAsString('bin', flush: true);
      await Process.run('chmod', ['+x', file.path]);
      // Check permission
      // permission executable b001001001 = 0x49
      expect((await file.stat()).mode & 0x49, 0x49);

      var dstFilePath = join(path, 'test.zip');
      ZipFileEncoder().zipDirectory(Directory(srcPath), filename: dstFilePath);

      // Read
      List<int> bytes = await File(dstFilePath).readAsBytes();

      // Decode the Zip file
      Archive archive = ZipDecoder().decodeBytes(bytes);

      var archiveFile = archive.first;
      // Fails! unixPermissions is null
      expect(archiveFile.unixPermissions & 0x49, 0x49);
    }
  });
}

[brendan-duncan]

I’ll look into fixing this up soon.

[jodymac]

Do we have a workaround for this yet?

[brendan-duncan]

Sorry, I've totally slacked on this. I think I have the solution, but will finish testing it before pushing it out.

[brendan-duncan]

I pushed an update that seemed to do what I expected, at least on macOS. I still need to do some testing to make sure I didn't break anything, but should be able to push it soon.

[magillus]

I was able to reproduce this on version 2.0.10 at Windows - did you merged this fix or it is on some branch? I would love to test it

[magillus]

I was able to reproduce this on version 2.0.10 at Windows - did you merged this fix or it is on some branch? I would love to test it

I think that was issue with Windows WLS (ubuntu) that unzip was not processing permissions - after checking with Dart (unit tests of this package) and also with 7-zip UI manager I confirm that permissions are propagated correctly

[magillus]

However when I add a file to zip with archive and set permissions of that file to 100777 (octets) then after unzipping the file in linux (subsystem) the permissions are not propagated and reset to 666 (rw). Maybe not bug in this package but I might miss something.

[magillus]

archive packages seems like reads and writes the permissions correctly. However somehow the linux (ubuntu) unzip command doesn't propagate the permission correctly. here is file permissions for file created with archive (int, octets, binary) (before <<16):

File: out/aws_lambda-square_number.main.zip/bootstrap
                : 33279 -> 100777 -> 00000000000000001000000111111111
                : 2180972544 -> 20177600000 -> 10000001111111110000000000000000

here is file permissions for file created with zip command on linux(ubuntu):

File: out/aws_lambda_linux.zip/bootstrap
                : 33279 -> 100777 -> 00000000000000001000000111111111
                : 2180972544 -> 20177600000 -> 10000001111111110000000000000000

they are identical, I wonder if there is some other "flag" on file during zipping that is different between archive and zip command line.