Fedora 38 - I/O zipping error using find command

[ghostanime2001 (an mac)]

@snowblind2005

There’s a high likely chance the zip version you are using has a zip file size limit of 4 gigabytes. At least test it and make sure that it can create a zip file larger than 4 gigabytes.

ok, I’ll zip a file that’s about 4 GB in size and then see if it succeeded.

as you can see here, I am trying to zip a file that is 4.6 GB in size but it fails to detect it.

@snowblind2005

It’s also likely then that the is file corruption on the device. It’s likely that certain files were not saved properly so they are marked as say 250k size on the file system, but there’s only 230k of actual data for the file. I could see this happening with digital cameras for various reasons. Have you attempted to validate that the files that threw the size errors are in fact valid?

I made sure that the file could be opened within android and opened within windows explorer when the phone is connected to the PC via USB cable. The file does open up on the phone and within windows 10 file explorer.

@snowblind2005

Using tools like ffprobe and ffplay from the ffmpeg package can easily help with that (ffmpeg is available in the RPM Fusion repository, it is not part of the core Fedora). Or just try to load them in an image editor.

How do I get this for ubuntu ?

@snowblind2005

I also question why are using find in the first place. The ‘-type f’ means regular file. Why would there be anything but regular files in the camera folder?

It’s not just the camera folder with .jpg files I’m worried about its other documents or songs or video files as well in other folders including the DCIM folder.

@snowblind2005

Have you tried just the basic tar command of something like;

tar -cvf /path/to/tarfile.tar /path/to/jpeg/files/*.jpg

tar command seemed to have worked but I’m more interested with zip file because it’s portable to windows and also with android. In addition, tar doesn’t seem to preserve accurate timestamps for files during the tar process especially from android, so zip is preferred in this regard.

@snowblind2005

Examples of the ffprobe and ffplay command are fairly simple;

ffprobe will probe the file and tell you what it is and potential errors with it.
ffprobe -i /path/to/media/file.jpg

This is the output that I got when using ffprobe.

@snowblind2005

ffplay will display the file to a window and display similar information as ffprobe. (To exit the window must be selected and hit q.).
ffplay -i /path/to/media/file.jpg

This is another video file with the biggest size in the DCIM/Camera folder

[jakfrost (Stephen Douglas Snow)]

@ghostanime2001

but I’m more interested with zip file because it’s portable to windows

I thought tar was available for windows. In any case doesn’t Z7 do tar files?

[ghostanime2001 (an mac)]

7z also makes tar files on windows but its highly unportable and unreliable

[snowblind2005 (Geoff King)]

Let’s start with the basics.

The zip command you gave in the first picture is an invalid command and the error of ‘nothing to do’ is the way of the zip command telling you that. You essentially told it to archive nothing.

In almost all archiving programs they need two path statements. One with the path to the archive, and one to the path of the file(s) you want archived. Where and when and how the archive program accepts these on the command line is specific to the program.

It is best practice to never, ever create the archive file in the same path as the files to be archived. As you have attempted to do in all your examples. This can essentially create a never ending loop, as the archiving program will eventually get to the archive file and attempt to archive it. You can see this error from the tar program with the “file is the archive; not dumped” error message. It is possible that the zip command does not recognize this and will attempt to archive the archive file until the file system is full or some other error occurs.

The tar archive program should preserve the timestamps of the files, however, it’s possible going from the various different file system types that they do not translate. I’m not sure on this.

Your tests were with local file system files. Let’s try to actually archive some of the files off of the mounted drive. First, start off in a local folder such as Downloads. Downloads is a good folder for a catch all of temporary files.

zip -0 -r ~/Downloads/zipfilename.zip ‘/run/user/1000/gvfs/dav:host=192.168.1.103,port=8080,ssl=false/sdcard/DCIM/Camera/’

I’m not sure if your mounted path may change when you mount it, like if the IP address changes. Be sure to make any corrections if I got it incorrect. Be sure to keep it within the ‘’ so the shell doesn’t attempt to interpret any of the odd characters in the path.

This should create a zip file with no compression ( -0) and recursive directories ( -r ), in the Downloads folder with the contents of the /sdcard/DCIM/Camera/ folder.

Let’s see how this goes.

Postnote:

The ffprobe and ffplay commands are for media files, like images and video files. They are part of the ffmpeg media encoding/decode package. So it not recognizing the zip file is expected. The error on the mp4 is a little concerning as that error usually comes up with really old, we’re talking 10 years old, mp4 and mov video files. It’s very possible that this goes back to your original question of the webdav mount just might not be able to do this properly. HTTP is probably one of the last and least reliable protocol for using as a file system.

[ghostanime2001 (an mac)]

@snowblind2005

The zip command you gave in the first picture is an invalid command and the error of ‘nothing to do’ is the way of the zip command telling you that. You essentially told it to archive nothing.

How can it zip nothing when i defined “.” after the zip filename catman.zip because im telling it to zip all the files in the current directory. In this case, the only file that exists in the directory is “E drive from exfat.zip”

@snowblind2005

It is best practice to never, ever create the archive file in the same path as the files to be archived

As you can see that the archive I want to save is not present initially in the containing folder i want to zip. But, just for the sake of example, let me make another zip and save it to a different location.

well oddly enough this seemed to copy all 4GB of zip file to another location. Please see the screeshot:

@snowblind2005

The tar archive program should preserve the timestamps of the files, however, it’s possible going from the various different file system types that they do not translate. I’m not sure on this.

The tar program does preserve all the timestamps but the reason why I don’t plan on using tar is because I can’t add files in specific levels of folders within windows using WinRAR. Only zip or rar files can do it. and since linux can’t read or manipulate rar files then zip files is the only one left to count on.

@snowblind2005

Your tests were with local file system files. Let’s try to actually archive some of the files off of the mounted drive. First, start off in a local folder such as Downloads. Downloads is a good folder for a catch all of temporary files.

zip -0 -r ~/Downloads/zipfilename.zip ‘/run/user/1000/gvfs/dav:host=192.168.1.103,port=8080,ssl=false/sdcard/DCIM/Camera/’

Actually temporary files are created at the location where the zip file is created and saved.

Seeing from this screenshot, the file still failed. What does ~/Downloads/zipfilename.zip mean ? the squiggly ~ sign ? are you saying the current working directory should be from the Downloads folder or should be in the / ? Let’s try both examples.

1. If the working directory is from the Downloads folder:

This still fails

2. If the working directory is from /

Again, if the current working directory is from the root / and using single quotes for the paths ’ ’ it still fails to save the zip

@snowblind2005

The error on the mp4 is a little concerning as that error usually comes up with really old, we’re talking 10 years old, mp4 and mov video files. It’s very possible that this goes back to your original question of the webdav mount just might not be able to do this properly. HTTP is probably one of the last and least reliable protocol for using as a file system.

If I use ubuntu 20.04, then mp4 files are zipping properly, then what makes this so different from ubuntu 20.04 ? even if ffprobe and ffplay was used in ubuntu 20.04 it shouldn’t return an error weather mp4 files are old or not because they are still used to this day.

[snowblind2005 (Geoff King)]

You appear to not actually want any help and to just argue with the responses you get.

I will no longer respond to this thread.

[ghostanime2001 (an mac)]

what ? how am i arguing ?

[ghostanime2001 (an mac)]

anyone else to offer suggestions or information why this is happening ?