This is not a actual micro sdcard. The android’s internal storage is just called sdcard. It isn’t an actual micro sd card. I dont have a micro sd card inserted into my galaxy s8
even then I’m using a webdav app it isn’t making temporary files on the phone and rewriting it back into fedora
Since the device is connected to the pc one could simply use the file manager to move the files. It only would need the phone to read the files and allow the transfer. Once the file is written to the pc it could be removed from the phone.
This could also be done from the command line very easily with the mv command, or a combination of cp & rm.
I’m trying to understand why it doesn’t work with a simple webdav app. I could’ve done this easily if I had some space but knowing that I barely have anything, even making a small zip containing one file is not possible because it would first need to be saved on the phone
Having only a tiny remaining space on the phone causes a problem since many apps require the use of ram or temporary file space to function. Clearing out some of that space with a tool that requires minimal extra space is mandatory and the webdav app seems to require more than would be necessary with the command line tools.
Start with the command line, then after some space is freed up it may be that your preferred app could manage the rest…
Tools that do not require space on the already full file system seem best for the task.
I am somewhat surprised that android allows the file system to fill up that much (99.6%) since linux normally reserves 5% to avoid those issues you are seeing.
I guess so…knowing that my pixel 7 has about 50 GB of storage remaining (while using the find and zip command works with the pixel 7) vs. 200 MB (fine and zip command doesn’t work here) or less on my galaxy s8…I’m not sure if that would be as big as a problem but let’s try to free up some space anyway
Buffer overflow: It looks like zip is a bit picky about file naming:
zip /var/tmp/a.zip 02\ -\ Why\ Can’t\ the\ English\?.mp3
*** buffer overflow detected ***: terminated
zip error: Interrupted (aborting)
cp 02\ -\ Why\ Can’t\ the\ English\?.mp3 02-WhyCanttheEnglish.mp3
zip /var/tmp/a.zip 02-WhyCanttheEnglish.mp3
adding: 02-WhyCanttheEnglish.mp3 (deflated 1%)
I’ve no idea yet what the reason is for zip to break out at this point, it’s not only the quote or question mark. Needs debugging.
Little debugging: routines local_to_wide string and local_to_utf8 string are involved, so
it has to do with the unusual characters in the file name.
Yes my point exacly, if you are having the same problem creating a zip file from a simple file, there has to be something else that is the problem. Also, what are all those slashes for? Have you tested it on a webdav mount so any problems correlate as closely as possible to mine? if you use zip -r -0 (no compression) does it make a difference? Why does a buffer overflow get detected when u are just zipping one file? In the second example, you just copied and renamed the original source file am I correct? What is your working directory?
It’s simple: the file name is read in and the file is opened correctly in zip. Then the name gets processed somehow for storage in the zip file. Either the character set of the file name is not recognized properly, or the conversion fails somehow. So it’s a bug in zip or in the libraries called by zip, where the file is coming from is not important.
The backslashes are escape characters, file names with spaces have to be
“file with space”, ‘file with space’, or file\ with\ space.
I can create a simple zip file when im on local storage using both the find & zip command together if the source files are stored locally. The problem arises when source files are on webdav and then saving into local storage.
I’m trying to debug but I’m afraid I’ve to give up. SELinux is off.
zip /var/tmp/a.zip 02\ -\ Why\ Can’t\ the\ English\?.mp3
*** buffer overflow detected ***: terminated
zip error: Interrupted (aborting)
zip /tmp/a.zip 02\ -\ Why\ Can’t\ the\ English\?.mp3
updating: 02 - Why Can’t the English?.mp3 (deflated 1%)
What’s going on here??? Destination directory determines what happens?
Edit: no magic, every location is wrong except if the zip file with that name already exists.
https://bugzilla.redhat.com/show_bug.cgi?id=2165653
Bug in zip. Maybe a side effect of recent build flag changes (the buffer overflow bug was always there, but now it’s exposed by stricter checks?).
Zip treats white space as a break between file names, so it cannot find that file. The shell also treats the ' as a special character and expects a closing quote with it.
If one were to enclose the full file name with single quotes it might work since zip may then see the quoted name as a single file name. (I have not tested this)
White space and special characters have been avoided from the beginning in unix-like OSes since a white space has always been considered a file name break and command line word separators.
All one needs to do to recognize the difference is to use the ls command in a directory where some files have white space or special characters. Those file names will appear with quotes when they are displayed.
A partial explanation is shown here, but does not cover all cases with all apps.
edit:
I just tested with the file being zipped having white space in the name and enclosing the file name in single quotes and it worked.
$ zip add 'Band Chart 8_5 X 11 Color.pdf'
adding: Band Chart 8_5 X 11 Color.pdf (deflated 24%)
This created the file add.zip containing the named file.
$ zip add2 Band\ Chart\ 8_5\ X\ 11\ Color.pdf
adding: Band Chart 8_5 X 11 Color.pdf (deflated 24%)
This also worked with every special character escaped and created the file ‘add2.zip’.
Special characters include '(){}[],$;"\.? and the white space characters with some I am sure I missed.
Wrong; the spaces are escaped. foo\ bar is the same as 'foo bar':
$ touch foo\ bar
$ zip foo.zip foo\ bar # no error
The error is from certain characters, e.g. ’ (right single quotation mark):
$ touch foo’
$ zip foo.zip foo’
*** buffer overflow detected ***: terminated
zip error: Interrupted (aborting)
Please see the linked bug for more info.
I don’t think that is a bug since the shell interprets the single quote before it gets to zip. A single quote must be escaped before it is treated as a literal character.
’ right single quotation mark (sometimes called “curly quote”), not ' apostrophe (aka “single quote”).
If it was an unmatched single quote, it would open a secondary prompt to continue input:
$ touch foo'
>
until you close the quote.
Yes, and I showed that just above.
But that was not escaped.
okay it seems we are getting off-topic but are you guys saying the reason for the buffer overflow error is because there are unescaped white spaces or special characters in the filename ? How can you explain why a normal filename such as 20230531_215584.jpg not being zipped?
The bug is not related to spaces, single quotes, special characters (in bash terms, like '"?), or escaping or not escaping characters. It’s related to the length of certain Unicode characters (like ’á©) being wrongly calculated.
I’m not sure why @computersavvy started speculating about spaces, quoting, and escaping, when the exact problem in the code was already identified.
@hmmsjan was also very close to identifying it and mentioned utf8 characters.
I don’t know. Do you have an example? Did you copy the file off the phone first, to narrow down the problem to zip and not something about gvfs or other factors?
What do you mean it is off?
what are your destination directories what locations?
Yes, as a matter of fact here is the test using a sample file that failed to zip with gvfs – 20220731_180105.jpg
Now, when I try to copy multiple files using cp -p -r instead of zipping them I am still getting alot of input/output errors just like zip I/O errors
