When I back up drives to a backup disk (using Carbon Copy Cloner), the size
of various folders is reported incorrectly. The people at CCC tell me this is
a known bug in MacOS.

How can I find out how much disk space a given folder is taking up? Checking
the Finder's 'Get Info' box confirms the erroneous size reported in the
Finder. There must be a simple Terminal command or something, but I'm not so
good with Terminal. The Unix du command gives reams of data on how much space
every single file is taking up.

Any suggestions? Can I force the Finder to recalculate the size of a folder?

Martin S Taylor

On 27/02/2024 14:59, Martin S Taylor wrote:
> When I back up drives to a backup disk (using Carbon Copy Cloner), the size
> of various folders is reported incorrectly. The people at CCC tell me this is
> a known bug in MacOS.
>
> How can I find out how much disk space a given folder is taking up? Checking
> the Finder's 'Get Info' box confirms the erroneous size reported in the
> Finder. There must be a simple Terminal command or something, but I'm not so
> good with Terminal. The Unix du command gives reams of data on how much space
> every single file is taking up.
>
> Any suggestions? Can I force the Finder to recalculate the size of a folder?
>
> Martin S Taylor
>

In Terminal

$ du -sh ~/Documents

to give the size of the Documents folder only.
--
Bruce Horrocks
Surrey, England

On 27 Feb 2024, Bruce Horrocks wrote
(in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):

> > How can I find out how much disk space a given folder is taking up? Checking
> > the Finder's 'Get Info' box confirms the erroneous size reported in the
> > Finder. There must be a simple Terminal command or something, but I'm not so
> > good with Terminal. The Unix du command gives reams of data on how much
> > space
> > every single file is taking up.
> >
> > Any suggestions? Can I force the Finder to recalculate the size of a folder?
> >
> > Martin S Taylor
>
> In Terminal
>
> $ du -sh ~/Documents
>
> to give the size of the Documents folder only.

Thanks - most helpful.

Now, is there a way to force the Finder to display this information, ie. to
recalculate the size of folders and their contents?

MST

Martin S Taylor <correspondence@mraermtoivnestthaiyslor.com> wrote:
> On 27 Feb 2024, Bruce Horrocks wrote
> (in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):
> > In Terminal
> >
> > $ du -sh ~/Documents
> >
> > to give the size of the Documents folder only.
>
> Thanks - most helpful.
>
> Now, is there a way to force the Finder to display this information, ie. to
> recalculate the size of folders and their contents?

There are two different 'sizes': the sizes of the files being stored, and
the disc space being used to store them. They aren't the same because
storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
Save a 1 byte file and it'll be rounded up to some number of blocks (eg
4KiB).

Finder's 'Get Info' tells you the number of bytes of the files and 'du'
tells you the amount of storage they occupy. With APFS the latter isn't
clear cut - for example, if you have a snapshot deleting a file may not
free up any space (the file still has to be stored for the snapshot). Also
APFS can transparently compress files, so change a file contents without
changing its length and yet the number of blocks it occupies may vary.

In essence the amount of space some arbitrary set of folders takes up is
increasingly disconnected from what would happen if you changed or deleted
them. So there's limited utility in exposing that to users.

'df -h' can show you disc occupancy by volume, which is another way to look
at this. But don't be surprised if the free space doesn't behave as you
would expect, due to the above.

Theo

On 28 Feb 2024, Theo wrote
(in article <3we*Up8Dz@news.chiark.greenend.org.uk>):

> There are two different 'sizes': the sizes of the files being stored, and
> the disc space being used to store them. They aren't the same because
> storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
> Save a 1 byte file and it'll be rounded up to some number of blocks (eg
> 4KiB).

Yes, I know this, but the discrepancy is too big for this to be the cause. I
have perfectly ordinary video files which run properly for half an hour, yet
the finder says they take up 20KB.

(du gives a more realistic figure.)

MST

On 28 Feb 2024 at 10:49:31 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
wrote:

> Martin S Taylor <correspondence@mraermtoivnestthaiyslor.com> wrote:
>> On 27 Feb 2024, Bruce Horrocks wrote
>> (in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):
>>> In Terminal
>>>
>>> $ du -sh ~/Documents
>>>
>>> to give the size of the Documents folder only.
>>
>> Thanks - most helpful.
>>
>> Now, is there a way to force the Finder to display this information, ie. to
>> recalculate the size of folders and their contents?
>
> There are two different 'sizes': the sizes of the files being stored, and
> the disc space being used to store them. They aren't the same because
> storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
> Save a 1 byte file and it'll be rounded up to some number of blocks (eg
> 4KiB).
>
> Finder's 'Get Info' tells you the number of bytes of the files and 'du'
> tells you the amount of storage they occupy. With APFS the latter isn't
> clear cut - for example, if you have a snapshot deleting a file may not
> free up any space (the file still has to be stored for the snapshot). Also
> APFS can transparently compress files, so change a file contents without
> changing its length and yet the number of blocks it occupies may vary.
>
> In essence the amount of space some arbitrary set of folders takes up is
> increasingly disconnected from what would happen if you changed or deleted
> them. So there's limited utility in exposing that to users.
>
> 'df -h' can show you disc occupancy by volume, which is another way to look
> at this. But don't be surprised if the free space doesn't behave as you
> would expect, due to the above.

Is it the case that, with more recent macOS versions, if I duplicate a folder
with lots of files in it (onto the same volume) that occupies some hundreds of
MB, that tasks essentially no space because at this point, all that has
happened is lots more directory entries? I ask this because doing just that
seems to take Finder no time at all. I then assume, that if this is the case,
that if some app wants to modify a block in the middle of such a duplicated
file, then the file is actually copied first and ceases to be just a pointer
to the old file and exists in its own right?

--
Tim

TimS <tim@streater.me.uk> wrote:
> On 28 Feb 2024 at 10:49:31 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
> wrote:
>
>> Martin S Taylor <correspondence@mraermtoivnestthaiyslor.com> wrote:
>>> On 27 Feb 2024, Bruce Horrocks wrote
>>> (in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):
>>>> In Terminal
>>>>
>>>> $ du -sh ~/Documents
>>>>
>>>> to give the size of the Documents folder only.
>>>
>>> Thanks - most helpful.
>>>
>>> Now, is there a way to force the Finder to display this information, ie. to
>>> recalculate the size of folders and their contents?
>>
>> There are two different 'sizes': the sizes of the files being stored, and
>> the disc space being used to store them. They aren't the same because
>> storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
>> Save a 1 byte file and it'll be rounded up to some number of blocks (eg
>> 4KiB).
>>
>> Finder's 'Get Info' tells you the number of bytes of the files and 'du'
>> tells you the amount of storage they occupy. With APFS the latter isn't
>> clear cut - for example, if you have a snapshot deleting a file may not
>> free up any space (the file still has to be stored for the snapshot). Also
>> APFS can transparently compress files, so change a file contents without
>> changing its length and yet the number of blocks it occupies may vary.
>>
>> In essence the amount of space some arbitrary set of folders takes up is
>> increasingly disconnected from what would happen if you changed or deleted
>> them. So there's limited utility in exposing that to users.
>>
>> 'df -h' can show you disc occupancy by volume, which is another way to look
>> at this. But don't be surprised if the free space doesn't behave as you
>> would expect, due to the above.
>
> Is it the case that, with more recent macOS versions, if I duplicate a folder
> with lots of files in it (onto the same volume) that occupies some hundreds of
> MB, that tasks essentially no space because at this point, all that has
> happened is lots more directory entries? I ask this because doing just that
> seems to take Finder no time at all. I then assume, that if this is the case,
> that if some app wants to modify a block in the middle of such a duplicated
> file, then the file is actually copied first and ceases to be just a pointer
> to the old file and exists in its own right?

It’s all about “Copy on Write” as explained by Howard Oakley.

<https://eclecticlight.co/2020/04/14/copy-move-and-clone-files-in-apfs-a-primer/comment-page-1/>

--
Cheers, Alan

Martin S Taylor <correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:

> On 27 Feb 2024, Bruce Horrocks wrote
> (in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):
>
> > > How can I find out how much disk space a given folder is taking up?
> > > Checking the Finder's 'Get Info' box confirms the erroneous size
> > > reported in the Finder. There must be a simple Terminal command or
> > > something, but I'm not so good with Terminal. The Unix du command
> > > gives reams of data on how much space every single file is taking up.
> > >
> > > Any suggestions? Can I force the Finder to recalculate the size of a
> > >folder?
> > >
> > > Martin S Taylor
> >
> > In Terminal
> >
> > $ du -sh ~/Documents
> >
> > to give the size of the Documents folder only.
>
> Thanks - most helpful.
>
> Now, is there a way to force the Finder to display this information, ie. to
> recalculate the size of folders and their contents?

Of no use to you probably, but I still have a File Buddy working.
It calculates folder sizes and item counts on demand,
by actualy finding the files and addding the sizes.
It usually returns a smaller folder size than the finder.

Not beyond Sierra...

Jan

On 28 Feb 2024 at 12:29:38 GMT, "Alan B" <alanrichardbarker@gmail.com.invalid>
wrote:

> TimS <tim@streater.me.uk> wrote:
>> On 28 Feb 2024 at 10:49:31 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
>> wrote:
>>
>>> Martin S Taylor <correspondence@mraermtoivnestthaiyslor.com> wrote:
>>>> On 27 Feb 2024, Bruce Horrocks wrote
>>>> (in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):
>>>>> In Terminal
>>>>>
>>>>> $ du -sh ~/Documents
>>>>>
>>>>> to give the size of the Documents folder only.
>>>>
>>>> Thanks - most helpful.
>>>>
>>>> Now, is there a way to force the Finder to display this information, ie. to
>>>> recalculate the size of folders and their contents?
>>>
>>> There are two different 'sizes': the sizes of the files being stored, and
>>> the disc space being used to store them. They aren't the same because
>>> storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
>>> Save a 1 byte file and it'll be rounded up to some number of blocks (eg
>>> 4KiB).
>>>
>>> Finder's 'Get Info' tells you the number of bytes of the files and 'du'
>>> tells you the amount of storage they occupy. With APFS the latter isn't
>>> clear cut - for example, if you have a snapshot deleting a file may not
>>> free up any space (the file still has to be stored for the snapshot). Also
>>> APFS can transparently compress files, so change a file contents without
>>> changing its length and yet the number of blocks it occupies may vary.
>>>
>>> In essence the amount of space some arbitrary set of folders takes up is
>>> increasingly disconnected from what would happen if you changed or deleted
>>> them. So there's limited utility in exposing that to users.
>>>
>>> 'df -h' can show you disc occupancy by volume, which is another way to look
>>> at this. But don't be surprised if the free space doesn't behave as you
>>> would expect, due to the above.
>>
>> Is it the case that, with more recent macOS versions, if I duplicate a folder
>> with lots of files in it (onto the same volume) that occupies some hundreds of
>> MB, that tasks essentially no space because at this point, all that has
>> happened is lots more directory entries? I ask this because doing just that
>> seems to take Finder no time at all. I then assume, that if this is the case,
>> that if some app wants to modify a block in the middle of such a duplicated
>> file, then the file is actually copied first and ceases to be just a pointer
>> to the old file and exists in its own right?
>
> It’s all about “Copy on Write” as explained by Howard Oakley.
>
> <https://eclecticlight.co/2020/04/14/copy-move-and-clone-files-in-apfs-a-primer/comment-page-1/>

Ah thanks, that's helpful.

But it does seem to me then that the OP cannot be much more sure that ls in
the Terminal is going to be a better bet than Finder.

--
Tim

On 28 Feb 2024 at 11:52:15 GMT, "Martin S Taylor"
<correspondence@mRaErMtOiVnEsTtHaIySlor.com> wrote:

> On 28 Feb 2024, Theo wrote
> (in article <3we*Up8Dz@news.chiark.greenend.org.uk>):
>
>> There are two different 'sizes': the sizes of the files being stored, and
>> the disc space being used to store them. They aren't the same because
>> storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
>> Save a 1 byte file and it'll be rounded up to some number of blocks (eg
>> 4KiB).
>
> Yes, I know this, but the discrepancy is too big for this to be the cause. I
> have perfectly ordinary video files which run properly for half an hour, yet
> the finder says they take up 20KB.
>
> (du gives a more realistic figure.)
>
> MST

I've been doing some file wrangling today, and it can take upwards of a
minute for Finder to even notice that files have been moved/renamed if
it was done on the command line without Finder's involvement. It's
incredibly poor.

I've not noticed Finder get the wrong file size stuck on things yet, but
I may just not have been looking - I mostly use columns view.

Cheers - Jaimie
--
The truth may be out there, but the lies are inside your head.
-- Terry Pratchett

On 28 Feb 2024 at 14:06:10 GMT, "TimS" <tim@streater.me.uk> wrote:

> On 28 Feb 2024 at 12:29:38 GMT, "Alan B" <alanrichardbarker@gmail.com.invalid>
> wrote:
>
>> TimS <tim@streater.me.uk> wrote:
>>> On 28 Feb 2024 at 10:49:31 GMT, "Theo" <theom+news@chiark.greenend.org.uk>
>>> wrote:
>>>
>>>> Martin S Taylor <correspondence@mraermtoivnestthaiyslor.com> wrote:
>>>>> On 27 Feb 2024, Bruce Horrocks wrote
>>>>> (in article<3c3e2707-691a-4ed0-b3e0-b6ac8bd72bf3@scorecrow.com>):
>>>>>> In Terminal
>>>>>>
>>>>>> $ du -sh ~/Documents
>>>>>>
>>>>>> to give the size of the Documents folder only.
>>>>>
>>>>> Thanks - most helpful.
>>>>>
>>>>> Now, is there a way to force the Finder to display this information, ie. to
>>>>> recalculate the size of folders and their contents?
>>>>
>>>> There are two different 'sizes': the sizes of the files being stored, and
>>>> the disc space being used to store them. They aren't the same because
>>>> storage is measured in blocks (perhaps 4KiB) but files are sized in bytes.
>>>> Save a 1 byte file and it'll be rounded up to some number of blocks (eg
>>>> 4KiB).
>>>>
>>>> Finder's 'Get Info' tells you the number of bytes of the files and 'du'
>>>> tells you the amount of storage they occupy. With APFS the latter isn't
>>>> clear cut - for example, if you have a snapshot deleting a file may not
>>>> free up any space (the file still has to be stored for the snapshot). Also
>>>> APFS can transparently compress files, so change a file contents without
>>>> changing its length and yet the number of blocks it occupies may vary.
>>>>
>>>> In essence the amount of space some arbitrary set of folders takes up is
>>>> increasingly disconnected from what would happen if you changed or deleted
>>>> them. So there's limited utility in exposing that to users.
>>>>
>>>> 'df -h' can show you disc occupancy by volume, which is another way to look
>>>> at this. But don't be surprised if the free space doesn't behave as you
>>>> would expect, due to the above.
>>>
>>> Is it the case that, with more recent macOS versions, if I duplicate a folder
>>> with lots of files in it (onto the same volume) that occupies some hundreds of
>>> MB, that tasks essentially no space because at this point, all that has
>>> happened is lots more directory entries? I ask this because doing just that
>>> seems to take Finder no time at all. I then assume, that if this is the case,
>>> that if some app wants to modify a block in the middle of such a duplicated
>>> file, then the file is actually copied first and ceases to be just a pointer
>>> to the old file and exists in its own right?
>>
>> It’s all about “Copy on Write” as explained by Howard Oakley.
>>
>> <https://eclecticlight.co/2020/04/14/copy-move-and-clone-files-in-apfs-a-primer/comment-page-1/>
>
> Ah thanks, that's helpful.
>
> But it does seem to me then that the OP cannot be much more sure that ls in
> the Terminal is going to be a better bet than Finder.

Right - the Terminal will also double-count two identical COW-ed files
that aren't actuall using double the bytes of the original. There's no
one-size-fits-all right answer.

As far as I know nothing will be able to run through a directory tree
and tell you how many actual bytes on disk it's *really* using.

'df' will accurately show you disk space that's free, but even that's
not the whole story as a bunch of stuff is purgeable if macOS wants the
space - old TM snapshots for example.

Cheers - Jaimie
--
"It has been said that man is a rational animal. All my life I
have been searching for evidence which could support this" -- Bertrand Russell

On 29 Feb 2024, Jaimie Vandenbergh wrote
(in article <l4b34cF9t3dU1@mid.individual.net>):

> > Yes, I know this, but the discrepancy is too big for this to be the cause. I
> > have perfectly ordinary video files which run properly for half an hour, yet
> > the finder says they take up 20KB.
> >
> > (du gives a more realistic figure.)
> >
> > MST
>
> I've been doing some file wrangling today, and it can take upwards of a
> minute for Finder to even notice that files have been moved/renamed if
> it was done on the command line without Finder's involvement. It's
> incredibly poor.
>
> I've not noticed Finder get the wrong file size stuck on things yet, but
> I may just not have been looking - I mostly use columns view.

Up to a minute is poor, but is understandable. I've found the Finder get the
size completely wrong and have it stuck there. It seems to be caused by
backup files created by Carbon Copy Cloner. Mike Bombich (Carbon Copy Cloner)
wrote to say:

> That's normal, and very annoying. Finder doesn't have an indication that it's
> working on refreshing that value, so it will gladly present stale and
> incorrect data for a while, and then eventually show the correct value
> unceremoniously. Eventually Finder will
> show the correct value.
I don't know how long his 'eventually' is, but it isn't doing it at all for
me.

Like Jaimie, I mostly use columns view, but when I need to know how big my
backups are, it would be nice if I could do so from the Finder and not have
to check the true value using du.

MST

On 29/02/2024 10:58, Martin S Taylor wrote:
> On 29 Feb 2024, Jaimie Vandenbergh wrote
> (in article <l4b34cF9t3dU1@mid.individual.net>):
>
>>> Yes, I know this, but the discrepancy is too big for this to be the cause. I
>>> have perfectly ordinary video files which run properly for half an hour, yet
>>> the finder says they take up 20KB.
>>>
>>> (du gives a more realistic figure.)
>>>
>>> MST
>>
>> I've been doing some file wrangling today, and it can take upwards of a
>> minute for Finder to even notice that files have been moved/renamed if
>> it was done on the command line without Finder's involvement. It's
>> incredibly poor.
>>
>> I've not noticed Finder get the wrong file size stuck on things yet, but
>> I may just not have been looking - I mostly use columns view.
>
> Up to a minute is poor, but is understandable. I've found the Finder get the
> size completely wrong and have it stuck there. It seems to be caused by
> backup files created by Carbon Copy Cloner. Mike Bombich (Carbon Copy Cloner)
> wrote to say:
>
>> That's normal, and very annoying. Finder doesn't have an indication that it's
>> working on refreshing that value, so it will gladly present stale and
>> incorrect data for a while, and then eventually show the correct value
>> unceremoniously. Eventually Finder will
>> show the correct value.
> I don't know how long his 'eventually' is, but it isn't doing it at all for
> me.
>
> Like Jaimie, I mostly use columns view, but when I need to know how big my
> backups are, it would be nice if I could do so from the Finder and not have
> to check the true value using du.

Would a Finder "Quick Action" be a workable alternative?

So the process would be: select a folder in Finder, right-click, choose
Quick Actions then choose "run du" or similar to get a popup showing the
size of the folder according to du.

If so then that's fairly easy to script and ping over, or share here.

--
Bruce Horrocks
Surrey, England

On 29 Feb 2024, Bruce Horrocks wrote
(in article<6df8557b-832a-41dd-9a15-868318fc9886@scorecrow.com>):

> > Like Jaimie, I mostly use columns view, but when I need to know how big my
> > backups are, it would be nice if I could do so from the Finder and not have
> > to check the true value using du.
>
> Would a Finder "Quick Action" be a workable alternative?
>
> So the process would be: select a folder in Finder, right-click, choose
> Quick Actions then choose "run du" or similar to get a popup showing the
> size of the folder according to du.
>
> If so then that's fairly easy to script and ping over, or share here.

That would be helpful - yes, please!

(Is it possible to build in the sudo option? Sometimes the contents of the
folders need authorisation.)

MST

On 29/02/2024 15:47, Martin S Taylor wrote:
> On 29 Feb 2024, Bruce Horrocks wrote
> (in article<6df8557b-832a-41dd-9a15-868318fc9886@scorecrow.com>):
>
>>> Like Jaimie, I mostly use columns view, but when I need to know how big my
>>> backups are, it would be nice if I could do so from the Finder and not have
>>> to check the true value using du.
>>
>> Would a Finder "Quick Action" be a workable alternative?
>>
>> So the process would be: select a folder in Finder, right-click, choose
>> Quick Actions then choose "run du" or similar to get a popup showing the
>> size of the folder according to du.
>>
>> If so then that's fairly easy to script and ping over, or share here.
>
> That would be helpful - yes, please!
>
> (Is it possible to build in the sudo option? Sometimes the contents of the
> folders need authorisation.)

I've put a file called "du.workflow" here
<https://www.icloud.com/iclouddrive/020rAiYp0Co1uquidX0E5zASw#du>

Download it, open it with Automator (don't double-click as that runs
Automator Installer) to first check that it is safe.

Then, when you are happy, double-click it to install. Automator
Installer "knows" it is a quick action and installs it into the relevant
directory (/Users/youruser/Library/Services).

That's it. Now select a file in the Finder, right-click, choose Quick
Actions and then du and it pops up a dialog giving the output of "du
-sh" run on the selected folder.

The first time you run it it will ask for access permissions - either to
desktop or removable media or wherever the folder you select is.
Sometimes the popup dialog can be hidden so best to minimise as many
windows as possible so you don't hide it.

--
Bruce Horrocks
Surrey, England

On 29 Feb 2024, Bruce Horrocks wrote
(in article<5e2977a8-1d72-4bbf-9b1f-6a485563ce23@scorecrow.com>):

> That's it. Now select a file in the Finder, right-click, choose Quick
> Actions and then du and it pops up a dialog giving the output of "du
> -sh" run on the selected folder.
>
> The first time you run it it will ask for access permissions - either to
> desktop or removable media or wherever the folder you select is.
> Sometimes the popup dialog can be hidden so best to minimise as many
> windows as possible so you don't hide it.

Terrific! Seems to do just what I need. Thank you!

MST

On 1 Mar 2024, Martin S Taylor wrote
(in article<0001HW.2B91CA37002B6D2E30A80238F@news.eternal-september.org>):

> > That's it. Now select a file in the Finder, right-click, choose Quick
> > Actions and then du and it pops up a dialog giving the output of "du
> > -sh" run on the selected folder.
> >
> > The first time you run it it will ask for access permissions - either to
> > desktop or removable media or wherever the folder you select is.
> > Sometimes the popup dialog can be hidden so best to minimise as many
> > windows as possible so you don't hide it.
>
> Terrific! Seems to do just what I need. Thank you!

Aha! A couple of problems. Firstly, it only works on folders, not files.
Specifically, it won't work on .sparsebundles even though they are a kind of
file-folder hybrid (as you know). And it's .sparsebundles which seem to
confuse the Finder particularly severely.

Secondly, sometimes it produces a string of 'Permission Denied' errors. I can
get round this in the Terminal by running du under sudo, but is it possible
with your little script to do this?

MST

On 01/03/2024 09:49, Martin S Taylor wrote:
> On 1 Mar 2024, Martin S Taylor wrote
> (in article<0001HW.2B91CA37002B6D2E30A80238F@news.eternal-september.org>):
>
>>> That's it. Now select a file in the Finder, right-click, choose Quick
>>> Actions and then du and it pops up a dialog giving the output of "du
>>> -sh" run on the selected folder.
>>>
>>> The first time you run it it will ask for access permissions - either to
>>> desktop or removable media or wherever the folder you select is.
>>> Sometimes the popup dialog can be hidden so best to minimise as many
>>> windows as possible so you don't hide it.
>>
>> Terrific! Seems to do just what I need. Thank you!
>
> Aha! A couple of problems. Firstly, it only works on folders, not files.
> Specifically, it won't work on .sparsebundles even though they are a kind of
> file-folder hybrid (as you know). And it's .sparsebundles which seem to
> confuse the Finder particularly severely.

Open the du.workflow file in Automator. At the top of the main pane at
the right is a setting "Workflow receives current". Change this from
"folders" to "files or folders".

I only have a couple of sparesebundles on my main drive and they seem to
work okay. E.g. an iPad backup is 77M according to Finder and 74M
according to du.

> Secondly, sometimes it produces a string of 'Permission Denied' errors. I can
> get round this in the Terminal by running du under sudo, but is it possible
> with your little script to do this?

Yes, but not recommended as you have to hard code your password.

Again, in Automator, edit the Run Shell Script action.

Change the line
du -sh "$f"
to read
echo "yourpassword" | sudo -S du -sh "$f"

Save and exit from Automator and double click to re-load as a Quick
Action. If it shows up twice, or doesn't replace the previous one then
you'll need to go into ~/Library/Services and manually delete the
previous du.workflow file.

--
Bruce Horrocks
Surrey, England