Solved Within ZIP archives, is this normal???

[909mjolnir]

Hi guys, I recently received a ZIP file which had file paths embedded in the file names (pathnames) so that when the archive was decompressed, there were very very very long names which each contained several "/" or "\" characters (I forget which it was). I had never seen this in DECOMPRESSED output before.

Also, when I browse normal archives of any kind, I never see long pathnames like that, I only see nested folders with the normal folder icons (nested directories).
I contacted the sender and they blew me off and claimed that it's all normal and functional on Ubuntu.

I'm on Manjaro 25 XFCE Linux 614 and not Ubuntu, so I can't test the ZIP output. I used file-roller on my system, but I also user xarchiver and engrampa interchangeably, and I've never encountered this before, even in my old PC Windows computer days or my Mac OS days.

Filenames like: "company/folder1/folder2/folder3/folder4/item.txt" instead of "item.txt" compressed in some nested directories.

I ended up using Thunar bulk rename to trim the filenames down to just the "item.txt" part, but it took a long time because there were dozens of files.

What are your thoughts on this?

 

[APTI]

it is normal for pathing information to be there. when the archive is decompressed the folders are recreated relatively and that way the structure is intact. you can't always trust what you see looking at the zip. you should see what it does when decompressed.
I am assuming that you mean the file name contains the folders but the folders are not created? if that is the case then either you have strange options set in what you use to decompress or you have a bad zip. That is the bottom line as I see it and I am a tech.

 

[909mjolnir]

Hmm, I'm thinking that maybe I didn't describe the problem correctly.
Usually, the archive DISPLAYS only the file names and the ICONS of the FOLDERS.
The filenames are usually simple names like "image.png" NOT (pathnames) "/usr/lib/image.png"

I know that internally, hidden from the end user the folder names and paths are there inside the archive as data, but not included in the name. The normal file name is "image.png" NOT with the "/" slashes.

Does that make sense? I suppose I could create a bogus ZIP and upload it to show you, but I'd rather not do that.

But maybe there's other formats of ZIP archives. And I'm just surprised.
At any rate, the decompressed ZIP did NOT create the nested folders. Instead it just created file(s) with silly wierd long names, and there was nothing to create the folders.

Are you understanding?

 

[APTI]

Hmm, I'm thinking that maybe I didn't describe the problem correctly.
Usually, the archive DISPLAYS only the file names and the ICONS of the FOLDERS.
The filenames are usually simple names like "image.png" NOT (pathnames) "/usr/lib/image.png"

I know that internally, hidden from the end user the folder names and paths are there inside the archive as data, but not included in the name. The normal file name is "image.png" NOT with the "/" slashes.

Does that make sense? I suppose I could create a bogus ZIP and upload it to show you, but I'd rather not do that.

But maybe there's other formats of ZIP archives. And I'm just surprised.
At any rate, the decompressed ZIP did NOT create the nested folders. Instead it just created file(s) with silly wierd long names, and there was nothing to create the folders.

Are you understanding?

I am understanding. it was the 2nd part of what I thought. If that is what you are getting then somebody didn't make the zip correctly or is using a version that is not standard. Either way I do not think the problem is on your end. I am pretty sure it is similar to people that us MS office and wonder why their 2025 version document won't read in everybody elses 2024 version.

you should start by asking what the people that made the zip are using to make it. I would be willing to bet it is not something the rest of the world is using or they have options set that are wrong. but you won't fix a problem on the other end which this clearly is. You will have to find out what they did to compress and match it on your end to do anything otherwise you will have to convince them to fix it on their end.

so my answer is still yes this is normal if the person on the other end made a mistake. you can say they have a PICNIC problem. PICNIC (Problem in chair not in computer) referring to them not you.

 

[theLegionWithin]

depends on where you got the file from. that sort of folder pathing looks very similar to some of my more... problematic... users at work. they just love to be so descriptive! then they complain when excessive path names break something.

trimming it down is a good idea.

 

[osprey]

Hmm, I'm thinking that maybe I didn't describe the problem correctly.
Usually, the archive DISPLAYS only the file names and the ICONS of the FOLDERS.
The filenames are usually simple names like "image.png" NOT (pathnames) "/usr/lib/image.png"

I know that internally, hidden from the end user the folder names and paths are there inside the archive as data, but not included in the name. The normal file name is "image.png" NOT with the "/" slashes.

Does that make sense? I suppose I could create a bogus ZIP and upload it to show you, but I'd rather not do that.

But maybe there's other formats of ZIP archives. And I'm just surprised.
At any rate, the decompressed ZIP did NOT create the nested folders. Instead it just created file(s) with silly wierd long names, and there was nothing to create the folders.

Are you understanding?

Are you using a GUI file manager that is not showing the full pathname of the files that have been extracted from the zip archive?

Do you want to move the files out of the directory tree with the long full pathnames that has come from the zip archive extraction, and move them to other directories of your own choosing?

If you want to move the files into a more convenient directory out of the directory tree with the lengthy filenames, it's very easy to do in the terminal, so if that's the case, let us know.

 

[909mjolnir]

Thanks for all the replies. I feel much better now about this.
Ultimately, I renamed the files myself, and put them into the correct folders manually.
I'm with APTI on this one, it's was indeed a PICNIC type of thing.

I won't worry about it.

About some of the questions: yes, I use a graphical GUI compressor/decompressor

It shows the paths, but doesn't alter the filenames to include the paths. (which is normal and fine), it just happens to use icons of the folders and the tree list and stuff. You can double click the folders to browse them, just like in the file manager of Linux.

Thanks for the offers of help. It got fixed on my own, I was just scratching my head wondering about it.
Thanks again.

I marked the original post as [SOLVED]