Zip files to Samba destination

[Som30ne]

Hello.

I was wondering if there is a way to select files on android device,
select "Zip" operation,
and choose a SAMBA folder as destination.

Trying to type
///LAN/ServerName/Folder into the zipTo dialog
resulted an error (zip is not supported, or something of that sort).

It would be a great feature to allow simple backup of complete folders to a PC.
(Instead of copying all the files to the PC and zip them on the PC)

-- crating a ZIP file on the device and transferring the ZIP to the PC is a problematic process,
as it will take longer, and the need to have a lot of spare storage on the device,
to hold the content expanded and zipped concurrently.

Thanks

[ghisler(Author)]

Currently it's not possible to pack directly to a plugin, sorry.

[Som30ne]

Thanks for the quick reply.

It would be interesting to know why that is.

Assuming a file is being opened for writing,
and a stream of bytes is sent as the content,
why is there a difference between copying an existing file,
and streaming a zip-stream to a plugin in general (and samba specifically)

[ghisler(Author)]

There is no random access to files with plugins. Random access means that you can reposition the current write position randomly and write there. This is needed when packing to write the actual compressed size of the packed file to the header in front of the compressed data after compressing it. There are variations of the ZIP format with the size header behind the data, but not all programs handle that well.

[Som30ne]

Thanks for the tech. info.
This makes me wonder how java ZIP stream is able to create zip files,
considering you can transmit this stream over TCP, and unzip it as stream on the other size,
while - it also creates a legal ZIP file when written to the disk.

[Usher]

Thanks for the tech. info.
This makes me wonder how java ZIP stream is able to create zip files,

Files may be stored in an archive with NO compression.

[Som30ne]

Files may be stored in an archive with NO compression.

Thanks for the reply.

Yes, they absolutely can, and yet, Java can actually compress them over TCP.

Below is a link to a small eclipse project, containing java sources that show simple java zip compression.
One of the classes is writing the output zip to a local file,
Another writes the output over a TCP connection, that eventually writes it into a file on the disk.

No 3rd party libraries used, only java built-in runtime classes.

To test if this is achieved by processing the full data in memory before writing to the output stream,
the program was ran with limited memory (-Xmx1024k = limited to 1MB of heap usage for data),
and could still produce a compressed zip entry of about 100MB,
with the required data, without crashing.
My conclusion from this,
is that the data is not accumulated into memory before transmitting it over the TCP.

(Not much error handling is done there, just a simple java program to demonstrate the capability,
almost any error encountered during it's operation would cause it to crash)

The output zip files were tested with 7Zip (windows) and with winRar.

https://mega.nz/#!gHBn1QIC!wo5IJECy59oFbHojMErW-2Gg6CNa0DYwzOqOFc5W8oA

Hope this could help with analysis of how this is done,
and that something similar will allow creating ZIP files directly to the SAMBA plugin.

Thanks

  

[Som30ne]

Just wondering if this request is considered as candidate for implementation

[JOUBE]

Just wondering if this request is considered as candidate for implementation

I think it is not. Because of the very simple solution (as you write yourself):

copying all the files to the PC and zip them on the PC

JOUBE

[Som30ne]

Just wondering if this request is considered as candidate for implementation

I think it is not. Because of the very simple solution (as you write yourself):

copying all the files to the PC and zip them on the PC

JOUBE

Yes, but this is a 2 step scenario that requires twice the disk size on the destination,
while Zipping directly to the destination is a single step that does not require extra space.