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;
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
add a comment |
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
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
add a comment |
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
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
centos zip unzip
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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
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
|
show 15 more comments
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
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
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
|
show 15 more comments
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
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
|
show 15 more comments
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
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
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
|
show 15 more comments
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
|
show 15 more comments
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?
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