Why is unzipped directory much smaller (4.0 K) than zipped (73.0 G)?File was deleted and then reappeared when folder was zippedCommand line alternative to rar.exe with complex switchesRemove sub directories / sub folder from zip + rar filesUnzip speed on Mac versus LinuxSuppress extraction of __MACOSX directory when unzippingHow to zip an archive while keeping some symlinks but not others? (OS X)How to zip folder to odt formatRezip file without creating temporariesZipping while preserving relative directories from anywhereSaving ZIP file attachments and reading them in Git Bash

Java guess the number

How can this map be coloured using four colours?

What's the correct term for a waitress in the Middle Ages?

How were concentration and extermination camp guards recruited?

Can't login after removing Flatpak

Why is quantum entanglement surprising?

Do any instruments not produce overtones?

Credit card offering 0.5 miles for every cent rounded up. Too good to be true?

In this example, which path would a monster affected by the Dissonant Whispers spell take?

Whats the next step after commercial fusion reactors?

Completing the square to find if quadratic form is positive definite.

Function to extract float from different price patterns

Building a road to escape Earth's gravity by making a pyramid on Antartica

How do I write "Show, Don't Tell" as an Asperger?

What happened to all the nuclear material being smuggled after the fall of the USSR?

Does an ice chest packed full of frozen food need ice? 18 day Grand Canyon trip

Who operates delivery flights for commercial airlines?

What's the correct term describing the action of sending a brand-new ship out into its first seafaring trip?

Can a magnetic field of an object be stronger than its gravity?

How is it possible that Gollum speaks Westron?

What can plausibly explain many of my very long and low-tech bridges?

Company did not petition for visa in a timely manner. Is asking me to work from overseas, but wants me to take a paycut

What is in `tex.print` or `tex.sprint`?

Why is the relationship between frequency and pitch exponential?



Why is unzipped directory much smaller (4.0 K) than zipped (73.0 G)?


File was deleted and then reappeared when folder was zippedCommand line alternative to rar.exe with complex switchesRemove sub directories / sub folder from zip + rar filesUnzip speed on Mac versus LinuxSuppress extraction of __MACOSX directory when unzippingHow to zip an archive while keeping some symlinks but not others? (OS X)How to zip folder to odt formatRezip file without creating temporariesZipping while preserving relative directories from anywhereSaving ZIP file attachments and reading them in Git Bash






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








38















I unzipped a zipped file using zip -l <filename> but what get is a dir much smaller than what it was before unzipping. Unzipped dir has all the files mostly videos. Why is the unzipped directory exactly 4.0k? Am I missing something?



Bash output of command ls -alh:



drwxrwsr-x 4 shubhankar gen011 4.0K May 19 15:47 Moments_in_Time_256x256_30fps
-rw-rw-r-- 1 shubhankar gen011 73G Mar 1 2018 Moments_in_Time_256x256_30fps.zip











share|improve this question



















  • 5





    Instead of ls -lah, try using du -h on the directory

    – hojusaram
    May 20 at 2:50






  • 15





    Maybe it would be a good idea to change the question title to something like "Why is my unzipped file only 4KB?"

    – therefromhere
    May 20 at 5:53






  • 4





    @therefromhere No, that would be completely changing the question, and it would be asking about a situation that is not occurring.

    – Scott
    May 22 at 1:04






  • 1





    This question is sooooooo duplicated. I wonder why is so highly voted

    – Pedro Lobito
    May 22 at 23:26

















38















I unzipped a zipped file using zip -l <filename> but what get is a dir much smaller than what it was before unzipping. Unzipped dir has all the files mostly videos. Why is the unzipped directory exactly 4.0k? Am I missing something?



Bash output of command ls -alh:



drwxrwsr-x 4 shubhankar gen011 4.0K May 19 15:47 Moments_in_Time_256x256_30fps
-rw-rw-r-- 1 shubhankar gen011 73G Mar 1 2018 Moments_in_Time_256x256_30fps.zip











share|improve this question



















  • 5





    Instead of ls -lah, try using du -h on the directory

    – hojusaram
    May 20 at 2:50






  • 15





    Maybe it would be a good idea to change the question title to something like "Why is my unzipped file only 4KB?"

    – therefromhere
    May 20 at 5:53






  • 4





    @therefromhere No, that would be completely changing the question, and it would be asking about a situation that is not occurring.

    – Scott
    May 22 at 1:04






  • 1





    This question is sooooooo duplicated. I wonder why is so highly voted

    – Pedro Lobito
    May 22 at 23:26













38












38








38


3






I unzipped a zipped file using zip -l <filename> but what get is a dir much smaller than what it was before unzipping. Unzipped dir has all the files mostly videos. Why is the unzipped directory exactly 4.0k? Am I missing something?



Bash output of command ls -alh:



drwxrwsr-x 4 shubhankar gen011 4.0K May 19 15:47 Moments_in_Time_256x256_30fps
-rw-rw-r-- 1 shubhankar gen011 73G Mar 1 2018 Moments_in_Time_256x256_30fps.zip











share|improve this question
















I unzipped a zipped file using zip -l <filename> but what get is a dir much smaller than what it was before unzipping. Unzipped dir has all the files mostly videos. Why is the unzipped directory exactly 4.0k? Am I missing something?



Bash output of command ls -alh:



drwxrwsr-x 4 shubhankar gen011 4.0K May 19 15:47 Moments_in_Time_256x256_30fps
-rw-rw-r-- 1 shubhankar gen011 73G Mar 1 2018 Moments_in_Time_256x256_30fps.zip








centos zip unzip






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 24 at 9:45







bluedroid

















asked May 20 at 0:16









bluedroidbluedroid

302136




302136







  • 5





    Instead of ls -lah, try using du -h on the directory

    – hojusaram
    May 20 at 2:50






  • 15





    Maybe it would be a good idea to change the question title to something like "Why is my unzipped file only 4KB?"

    – therefromhere
    May 20 at 5:53






  • 4





    @therefromhere No, that would be completely changing the question, and it would be asking about a situation that is not occurring.

    – Scott
    May 22 at 1:04






  • 1





    This question is sooooooo duplicated. I wonder why is so highly voted

    – Pedro Lobito
    May 22 at 23:26












  • 5





    Instead of ls -lah, try using du -h on the directory

    – hojusaram
    May 20 at 2:50






  • 15





    Maybe it would be a good idea to change the question title to something like "Why is my unzipped file only 4KB?"

    – therefromhere
    May 20 at 5:53






  • 4





    @therefromhere No, that would be completely changing the question, and it would be asking about a situation that is not occurring.

    – Scott
    May 22 at 1:04






  • 1





    This question is sooooooo duplicated. I wonder why is so highly voted

    – Pedro Lobito
    May 22 at 23:26







5




5





Instead of ls -lah, try using du -h on the directory

– hojusaram
May 20 at 2:50





Instead of ls -lah, try using du -h on the directory

– hojusaram
May 20 at 2:50




15




15





Maybe it would be a good idea to change the question title to something like "Why is my unzipped file only 4KB?"

– therefromhere
May 20 at 5:53





Maybe it would be a good idea to change the question title to something like "Why is my unzipped file only 4KB?"

– therefromhere
May 20 at 5:53




4




4





@therefromhere No, that would be completely changing the question, and it would be asking about a situation that is not occurring.

– Scott
May 22 at 1:04





@therefromhere No, that would be completely changing the question, and it would be asking about a situation that is not occurring.

– Scott
May 22 at 1:04




1




1





This question is sooooooo duplicated. I wonder why is so highly voted

– Pedro Lobito
May 22 at 23:26





This question is sooooooo duplicated. I wonder why is so highly voted

– Pedro Lobito
May 22 at 23:26










1 Answer
1






active

oldest

votes


















150














The size of a directory as shown in your screenshot isn't the sum of the size of the contents, it is the size of the meta-data associated with the directory - file names, etc.



https://unix.stackexchange.com/questions/55/what-does-size-of-a-directory-mean-in-output-of-ls-l-command



To find out how much space the directory contents are using, you can use



du -sh /path/to/directory






share|improve this answer


















  • 21





    And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

    – Peter A. Schneider
    May 20 at 11:44






  • 1





    To be fair the filesystem could cache the total size of each directory in the metadata

    – poizan42
    May 20 at 14:01






  • 11





    @poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

    – Simon Richter
    May 20 at 14:11






  • 25





    @poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

    – Erwan
    May 20 at 15:37






  • 8





    @poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

    – Voo
    May 21 at 11:53










protected by Community May 24 at 17:33



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?














1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









150














The size of a directory as shown in your screenshot isn't the sum of the size of the contents, it is the size of the meta-data associated with the directory - file names, etc.



https://unix.stackexchange.com/questions/55/what-does-size-of-a-directory-mean-in-output-of-ls-l-command



To find out how much space the directory contents are using, you can use



du -sh /path/to/directory






share|improve this answer


















  • 21





    And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

    – Peter A. Schneider
    May 20 at 11:44






  • 1





    To be fair the filesystem could cache the total size of each directory in the metadata

    – poizan42
    May 20 at 14:01






  • 11





    @poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

    – Simon Richter
    May 20 at 14:11






  • 25





    @poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

    – Erwan
    May 20 at 15:37






  • 8





    @poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

    – Voo
    May 21 at 11:53
















150














The size of a directory as shown in your screenshot isn't the sum of the size of the contents, it is the size of the meta-data associated with the directory - file names, etc.



https://unix.stackexchange.com/questions/55/what-does-size-of-a-directory-mean-in-output-of-ls-l-command



To find out how much space the directory contents are using, you can use



du -sh /path/to/directory






share|improve this answer


















  • 21





    And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

    – Peter A. Schneider
    May 20 at 11:44






  • 1





    To be fair the filesystem could cache the total size of each directory in the metadata

    – poizan42
    May 20 at 14:01






  • 11





    @poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

    – Simon Richter
    May 20 at 14:11






  • 25





    @poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

    – Erwan
    May 20 at 15:37






  • 8





    @poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

    – Voo
    May 21 at 11:53














150












150








150







The size of a directory as shown in your screenshot isn't the sum of the size of the contents, it is the size of the meta-data associated with the directory - file names, etc.



https://unix.stackexchange.com/questions/55/what-does-size-of-a-directory-mean-in-output-of-ls-l-command



To find out how much space the directory contents are using, you can use



du -sh /path/to/directory






share|improve this answer













The size of a directory as shown in your screenshot isn't the sum of the size of the contents, it is the size of the meta-data associated with the directory - file names, etc.



https://unix.stackexchange.com/questions/55/what-does-size-of-a-directory-mean-in-output-of-ls-l-command



To find out how much space the directory contents are using, you can use



du -sh /path/to/directory







share|improve this answer












share|improve this answer



share|improve this answer










answered May 20 at 0:43









ivanivanivanivan

2,054169




2,054169







  • 21





    And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

    – Peter A. Schneider
    May 20 at 11:44






  • 1





    To be fair the filesystem could cache the total size of each directory in the metadata

    – poizan42
    May 20 at 14:01






  • 11





    @poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

    – Simon Richter
    May 20 at 14:11






  • 25





    @poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

    – Erwan
    May 20 at 15:37






  • 8





    @poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

    – Voo
    May 21 at 11:53













  • 21





    And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

    – Peter A. Schneider
    May 20 at 11:44






  • 1





    To be fair the filesystem could cache the total size of each directory in the metadata

    – poizan42
    May 20 at 14:01






  • 11





    @poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

    – Simon Richter
    May 20 at 14:11






  • 25





    @poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

    – Erwan
    May 20 at 15:37






  • 8





    @poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

    – Voo
    May 21 at 11:53








21




21





And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

– Peter A. Schneider
May 20 at 11:44





And the answer to just why this design decision was made is left to the reader (after running both commands ;-) ).

– Peter A. Schneider
May 20 at 11:44




1




1





To be fair the filesystem could cache the total size of each directory in the metadata

– poizan42
May 20 at 14:01





To be fair the filesystem could cache the total size of each directory in the metadata

– poizan42
May 20 at 14:01




11




11





@poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

– Simon Richter
May 20 at 14:11





@poizan42, no, because files could be hardlinked, so you cannot just sum up sizes when walking up the hierarchy.

– Simon Richter
May 20 at 14:11




25




25





@poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

– Erwan
May 20 at 15:37





@poizan42 that would be quite inefficient, requiring the filesystem to update all the parents directories at every change (including root dir, its size would change constantly).

– Erwan
May 20 at 15:37




8




8





@poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

– Voo
May 21 at 11:53






@poizan42 That solution is even worse than it would appear on first glance (which is already unacceptably slow): Inodes do not store references to the directories that link them, but just a count. Meaning you'd also have to store a whole lot more of metadata with each inode and worry about keeping everything in sync. Quite an awful lot of overhead and complexity for what would be a rarely used feature.

– Voo
May 21 at 11:53






protected by Community May 24 at 17:33



Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



Would you like to answer one of these unanswered questions instead?



Popular posts from this blog

RemoteApp sporadic failureWindows 2008 RemoteAPP client disconnects within a matter of minutesWhat is the minimum version of RDP supported by Server 2012 RDS?How to configure a Remoteapp server to increase stabilityMicrosoft RemoteApp Active SessionRDWeb TS connection broken for some users post RemoteApp certificate changeRemote Desktop Licensing, RemoteAPPRDS 2012 R2 some users are not able to logon after changed date and time on Connection BrokersWhat happens during Remote Desktop logon, and is there any logging?After installing RDS on WinServer 2016 I still can only connect with two users?RD Connection via RDGW to Session host is not connecting

How to write a 12-bar blues melodyI-IV-V blues progressionHow to play the bridges in a standard blues progressionHow does Gdim7 fit in C# minor?question on a certain chord progressionMusicology of Melody12 bar blues, spread rhythm: alternative to 6th chord to avoid finger stretchChord progressions/ Root key/ MelodiesHow to put chords (POP-EDM) under a given lead vocal melody (starting from a good knowledge in music theory)Are there “rules” for improvising with the minor pentatonic scale over 12-bar shuffle?Confusion about blues scale and chords

Esgonzo ibérico Índice Descrición Distribución Hábitat Ameazas Notas Véxase tamén "Acerca dos nomes dos anfibios e réptiles galegos""Chalcides bedriagai"Chalcides bedriagai en Carrascal, L. M. Salvador, A. (Eds). Enciclopedia virtual de los vertebrados españoles. Museo Nacional de Ciencias Naturales, Madrid. España.Fotos