Following my recent rebuild of an external drive, some files have the size listed wrongly. Files which I know to be several GB in size (and are perfectly readable by the video editing programs they belong to) are listed as 1KB in the Finder. They're also listed as 1KB in Terminal, using ls -l
What's going on, and how can I cure it? Restarting the Mac doesn't work, ejecting and remounting the disk doesn't work...
Martin S Taylor <correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:
Following my recent rebuild of an external drive, some files have the size >> listed wrongly. Files which I know to be several GB in size (and are
perfectly readable by the video editing programs they belong to) are listed >> as 1KB in the Finder. They're also listed as 1KB in Terminal, using ls -l
What's going on, and how can I cure it? Restarting the Mac doesn't work,
ejecting and remounting the disk doesn't work...
Howard Oakley has written recently a series of articles about Finder
issues.
<https://eclecticlight.co>
Here’s the most recent.
<https://eclecticlight.co/2023/04/17/the-finder-confuses-with-wildly-inaccurat
e-figures-for-available-space/>
On 2023-04-18, Martin S Taylor<correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:
On 18 Apr 2023, Alan B wrote
(in article<u1m0qe$3h8t3$1@alanrichardbarker.eternal-september.org>):
Here’s the most recent.
<https://eclecticlight.co/2023/04/17/the-finder-confuses-with-wildly-inaccu
rat
e-figures-for-available-space/>
Yes, I saw that. It refers to the Finder's estimate of how much free space is
available on the drive. My problem is different, I think. The size of an individual, specific file is misreported.
And I mis-titled the thread, since it's not a Finder problem per se; Terminal
gives the identical wrong file size when I run ls -l
Yea could be a different issue? What happens if you copy one of these files (assuming you
have enough space, given some are quite large!) - is the size of the new file still shown
as the same as the original? Presumably running DFA makes no difference?
On 18 Apr 2023, Alan B wrote
(in article<u1m0qe$3h8t3$1@alanrichardbarker.eternal-september.org>):
Here’s the most recent.
<https://eclecticlight.co/2023/04/17/the-finder-confuses-with-wildly-inaccurat
e-figures-for-available-space/>
Yes, I saw that. It refers to the Finder's estimate of how much free space is available on the drive. My problem is different, I think. The size of an individual, specific file is misreported.
And I mis-titled the thread, since it's not a Finder problem per se; Terminal gives the identical wrong file size when I run ls -l
Following my recent rebuild of an external drive, some files have the size >listed wrongly. Files which I know to be several GB in size (and are >perfectly readable by the video editing programs they belong to) are listed >as 1KB in the Finder. They're also listed as 1KB in Terminal, using ls -l
In article<0001HW.29EEB97500036DD170001029538F@news.eternal-september.org>, Martin S Taylor <correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:
Following my recent rebuild of an external drive, some files have the size listed wrongly. Files which I know to be several GB in size (and are perfectly readable by the video editing programs they belong to) are listed as 1KB in the Finder. They're also listed as 1KB in Terminal, using ls -l
That's very strangs. Are you sure you are looking at the exact same
file?
How big does "stat" think the file is? Or "wc"?
Also, what do you mean by "rebuild"?
How big does "stat" think the file is? Or "wc"?
I'm not sure how to use those. wc says the file is a directory. (It's a Final >Cut Pro archive file, so is probably in some directory format.)
In article<0001HW.29EEF5120011669770000BCB338F@news.eternal-september.org>,
Martin S Taylor <correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:
How big does "stat" think the file is? Or "wc"?
I'm not sure how to use those. wc says the file is a directory. (It's a Final
Cut Pro archive file, so is probably in some directory format.)
If it's a directory, the size displayed by ls is just the size of the directory object itself, not the size of the files inside it.
Can you post the ls output?
On 18 Apr 2023, Alan B wrote
(in article<u1m6k6$3i5jm$1@alanrichardbarker.eternal-september.org>):
On 2023-04-18, Martin S Taylor<correspondence@mRaErMtOiVnEsTtHaIySlor.com> >> wrote:
On 18 Apr 2023, Alan B wrote
(in article<u1m0qe$3h8t3$1@alanrichardbarker.eternal-september.org>):
Here’s the most recent.
<https://eclecticlight.co/2023/04/17/the-finder-confuses-with-wildly-inaccu
rat
e-figures-for-available-space/>
Yes, I saw that. It refers to the Finder's estimate of how much free space >> > is
available on the drive. My problem is different, I think. The size of an >> > individual, specific file is misreported.
And I mis-titled the thread, since it's not a Finder problem per se;
Terminal
gives the identical wrong file size when I run ls -l
Yea could be a different issue? What happens if you copy one of these files >> (assuming you
have enough space, given some are quite large!) - is the size of the new file
still shown
as the same as the original? Presumably running DFA makes no difference?
Correct on both counts. File size is as it should be if I copy, and running Disk Utility makes no difference.
Having read Richard's Q's, I realise now you are dealing with a s/w package which I guess
could be regarded as a 'fancy' directory structure complete with its own sub-directories
and files therein. The apparent size as seen by ls -l is sort of misleading as many GB of
data could be 'hidden' within.
On 18 Apr 2023, Alan B wrote
(in article<u1musd$3m305$1@alanrichardbarker.eternal-september.org>):
Having read Richard's Q's, I realise now you are dealing with a s/w package >> which I guess
could be regarded as a 'fancy' directory structure complete with its own
sub-directories
and files therein. The apparent size as seen by ls -l is sort of misleading >> as many GB of
data could be 'hidden' within.
This is correct. But is it not weird and confusing that what appears in the Finder as a file of less than 1kB, if duplicated, now appears as a file of 5GB?
On 18 Apr 2023, Alan B wrote
(in article<u1musd$3m305$1@alanrichardbarker.eternal-september.org>):
Having read Richard's Q's, I realise now you are dealing with a s/w package >> which I guess
could be regarded as a 'fancy' directory structure complete with its own
sub-directories
and files therein. The apparent size as seen by ls -l is sort of misleading >> as many GB of
data could be 'hidden' within.
This is correct. But is it not weird and confusing that what appears in the Finder as a file of less than 1kB, if duplicated, now appears as a file of 5GB?
On 18 Apr 2023, Richard Tobin wrote
(in article <u1mg83$as6$1@macpro.inf.ed.ac.uk>):
In article<0001HW.29EEF5120011669770000BCB338F@news.eternal-september.org>, >>
Martin S Taylor <correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:
How big does "stat" think the file is? Or "wc"?
I'm not sure how to use those. wc says the file is a directory. (It's a
Final
Cut Pro archive file, so is probably in some directory format.)
If it's a directory, the size displayed by ls is just the size of the
directory object itself, not the size of the files inside it.
Can you post the ls output?
mst@MSTs-iMac-Pro ~ % ls -l /Volumes/Icy\ Box/Other\ original\ videos/OpSoc\ \&\ Imperial\ Opera/Follies\ workshop/Stage\ Right.fcarch
total 8
drwxrwxrwx 3 mst staff 96 3 Jul 2022 DCIM
-rwxrwxrwx 1 mst staff 868 4 Jul 2022 FCArchMetadata.plist
drwxrwxrwx 3 mst staff 96 3 Jul 2022 PRIVATE
mst@MSTs-iMac-Pro ~ %
As far as the Finder is concerned, it just looks like one file of 868 bytes. I have to "Show Package Contents" if I want to see what's inside it. If I copy it to somewhere else, the Finder now sees what appears to be one file of several GB.
As for why the Finder is showing the size of the directory instead of treating it as a bundle - well it's obviously lost track of the fact the
file is a bundle. And that's probably because the Icy Box isn't storing
the relevant information. (What filesystem is it formatted as?)
You /might/ be able to reset it by copying the directory off the Icy Box
back onto the Mac, then renaming it with some harmless extension (e.g.
.zzz), then renaming back to .fcarch. The theory is that the Mac should already know that .fcarch files should be bundles and it then recognises
it as such.
If not then you might need to do 'mdls' on a working .fcarch file, then repeat for the broken one, see which attribute(s) are missing and
re-create them. Hopefully it's an obvious one that has 'bundle' in the name.
On 18 Apr 2023, Bruce Horrocks wrote
(in article<ce5a7bc4-30c3-c135-d8e4-c55834adb0b7@scorecrow.com>):
As for why the Finder is showing the size of the directory instead of
treating it as a bundle - well it's obviously lost track of the fact the
file is a bundle. And that's probably because the Icy Box isn't storing
the relevant information. (What filesystem is it formatted as?)
I've found the problem on a couple of disks, including a networked disk. Icy Box is formatted as APFS.
You /might/ be able to reset it by copying the directory off the Icy Box
back onto the Mac, then renaming it with some harmless extension (e.g.
.zzz), then renaming back to .fcarch. The theory is that the Mac should
already know that .fcarch files should be bundles and it then recognises
it as such.
That works - even without the renaming. Simply copying the file to a new disk gives its correct size. But if I *know* the Finder is giving the wrong size, then I'm not inconvenienced (much): I can do a du or something to find the correct size. It's when I look at a folder containing the .fcarch file, and the Finder tells me it contains 15GB (or something) when it actually contains 250GB - now I have a problem!
If not then you might need to do 'mdls' on a working .fcarch file, then
repeat for the broken one, see which attribute(s) are missing and
re-create them. Hopefully it's an obvious one that has 'bundle' in the name.
I did this. The attributes it lists are the same, but for the obvious differences such as file name, (true) size, and creation/modification dates. Nothing suspicious to see at all.
Could it be that somehow the .DS file for the containing folder has got corrupted? How would I know? How would I sort that?
The rename suggestion was to see if it avoided the need to copy a large
file.
If renaming fixes the issue - and the fix sticks i.e. doesn't revert
back to being wrong - then a simple bulk rename to .zzz and back again
would fix them all in one go.
Remember that simply copying a file in APFS doesn't allocate any new
blocks, so that might be the easiest fix for Martin.
On 19/04/2023 18:16, Bruce Horrocks wrote:
The rename suggestion was to see if it avoided the need to copy a large file.
If renaming fixes the issue - and the fix sticks i.e. doesn't revert
back to being wrong - then a simple bulk rename to .zzz and back again would fix them all in one go.
Remember that simply copying a file in APFS doesn't allocate any new
blocks, so that might be the easiest fix for Martin.
Remember that simply copying a file in APFS doesn't allocate any new
blocks, so that might be the easiest fix for Martin.
On 22 Apr 2023, Chris Ridd wrote
(in article <u20tq1$3alcg$1@dont-email.me>):
Remember that simply copying a file in APFS doesn't allocate any new
blocks, so that might be the easiest fix for Martin.
If I copy a file from one volume to another (but within the same APFS container) does that allocate new blocks?
MST
On 22 Apr 2023, Chris Ridd wrote
(in article <u20tq1$3alcg$1@dont-email.me>):
Remember that simply copying a file in APFS doesn't allocate any new
blocks, so that might be the easiest fix for Martin.
If I copy a file from one volume to another (but within the same APFS container) does that allocate new blocks?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 164:13:51 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,517 |