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

Wikipedia:Vital articles Мазмуну Biography - Өмүр баян Philosophy and psychology - Философия жана психология Religion - Дин Social sciences - Коомдук илимдер Language and literature - Тил жана адабият Science - Илим Technology - Технология Arts and recreation - Искусство жана эс алуу History and geography - Тарых жана география Навигация менюсу

Bruxelas-Capital Índice Historia | Composición | Situación lingüística | Clima | Cidades irmandadas | Notas | Véxase tamén | Menú de navegacióneO uso das linguas en Bruxelas e a situación do neerlandés"Rexión de Bruxelas Capital"o orixinalSitio da rexiónPáxina de Bruselas no sitio da Oficina de Promoción Turística de Valonia e BruxelasMapa Interactivo da Rexión de Bruxelas-CapitaleeWorldCat332144929079854441105155190212ID28008674080552-90000 0001 0666 3698n94104302ID540940339365017018237

What should I write in an apology letter, since I have decided not to join a company after accepting an offer letterShould I keep looking after accepting a job offer?What should I do when I've been verbally told I would get an offer letter, but still haven't gotten one after 4 weeks?Do I accept an offer from a company that I am not likely to join?New job hasn't confirmed starting date and I want to give current employer as much notice as possibleHow should I address my manager in my resignation letter?HR delayed background verification, now jobless as resignedNo email communication after accepting a formal written offer. How should I phrase the call?What should I do if after receiving a verbal offer letter I am informed that my written job offer is put on hold due to some internal issues?Should I inform the current employer that I am about to resign within 1-2 weeks since I have signed the offer letter and waiting for visa?What company will do, if I send their offer letter to another company