How can I remove all zero size files recursively

[Cesar Romani]

I'd like to remove recursively all files of size zero.

Many thanks in advance,

--
Cesar

[billious]

On 3/10/2012 23:30, Cesar Romani wrote:
> I'd like to remove recursively all files of size zero.
>
> Many thanks in advance,
>

for /f "delims=" %i in ('dir /s/b/a-d d:\directory\*.*') do if %~zi==0
del "%i"

(all as one line from the prompt - change each "%" to "%%' to execute
from a batch line)

BUT

Try

...==0 >>testfilename.txt echo "%i"

first, which will create testfilename.txt with a list of the files the
first line will delete. Better safe than sorry...!

[JJ]

Using "FOR /R" and "%~zI" would be safer and faster since it doesn't use
parsing. e.g.:

for /r d:\directory %I in (*) do if %~zI == 0 del "%I"

The "%~zI" returns the file size pointed by "%I". Check "FOR /?" for
others.

[Todd Vargo]

FOR /R and FOR /D switches are unreliable. Sorry, I don't have details
for the exact cause of the failures, but this is the reason 'DIR...'
syntax is recommended with the FOR command instead of using the /R and
/D switches.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

[Liviu]

"Todd Vargo" wrote...

> On 10/4/2012 8:07 PM, JJ wrote:
>>

>> Using "FOR /R" and "%~zI" would be safer and faster [...]

>
> FOR /R and FOR /D switches are unreliable. Sorry, I don't have
> details for the exact cause of the failures

And I remember foxidrive and billious saying, on separate occasions,
that they remembered of a problem with for/d, but couldn't recall the
details, either ;-)

http://groups.google.com/group/alt.msdos.batch.nt/msg/dad041618358a0a5?hl=en
http://groups.google.com/group/alt.msdos.batch.nt/msg/4e42e7c4fa25dddc?hl=en

Seriously, I'd be curious about any specifics, if somebody remembered.

> but this is the reason 'DIR...' syntax is recommended with the FOR
> command instead of using the /R and /D switches.

Downside of the DIR command in a FOR/F loop is that it fails on names
with characters outside the current codepage. This is not a limitation
of DIR itself, but of the FOR/F loop which converts the output of any
given command (from unicode) to the current codepage before tokenizing.
In contrast, FOR/D/R loops handle such "international" names just fine.

Liviu

[foxidrive]

On Saturday 06/10/2012 14:41, Liviu wrote:
> "Todd Vargo" wrote...
>> On 10/4/2012 8:07 PM, JJ wrote:
>>>
>>> Using "FOR /R" and "%~zI" would be safer and faster [...]
>>
>> FOR /R and FOR /D switches are unreliable. Sorry, I don't have
>> details for the exact cause of the failures
>
> And I remember foxidrive and billious saying, on separate occasions,
> that they remembered of a problem with for/d, but couldn't recall the
> details, either ;-)
>
> http://groups.google.com/group/alt.msdos.batch.nt/msg/dad041618358a0a5?hl=en
> http://groups.google.com/group/alt.msdos.batch.nt/msg/4e42e7c4fa25dddc?hl=en
>
> Seriously, I'd be curious about any specifics, if somebody remembered.

Yes, I recall one issue. It was when specifying a starting directory and it has long filename elements.

I don't have an example, and know that it only goes belly up on some combinations.

>> but this is the reason 'DIR...' syntax is recommended with the FOR
>> command instead of using the /R and /D switches.
>
> Downside of the DIR command in a FOR/F loop is that it fails on names
> with characters outside the current codepage. This is not a limitation
> of DIR itself, but of the FOR/F loop which converts the output of any
> given command (from unicode) to the current codepage before tokenizing.
> In contrast, FOR/D/R loops handle such "international" names just fine.
>
> Liviu
>
>

--
foxi

[billious]

I believe we're really getting to the outer limits of applicability of a
language that was originally designed for the English-speaking
cognescenti to use.

We now have different editions of different releases in different
languages, code pages, service packs, privilege levels and seemingly a
thousand and one other complicating factors - compounded by an
unprofessional language-maintenance regime apparently run to implement
half-baked changes at random. Naturally, all this is silently modified
in the background by seemingly-daily patches that may or may not be
applied, succeed or fix any problem that may have been encountered.

It may be that problems found in the past have been fixed either with a
patch or with a new release. Once a problem has been found and a
workaround devised, we're likely to continue to follow the voodoo
ceremony because we aren't going to revisit the same old problems daily
"just in case" it's been fixed in the meantime. A fix released last week
or last month or last year hasn't necessarily been applied to any
particular machine or may not have been released for "end of life"
editions - the possible permutations appear endless.

[frank.w...@gmail.com]

From "Liviu" :

>And I remember foxidrive and billious saying, on
>separate occasions,
>that they remembered of a problem with for/d, but
>couldn't recall the
>details, either ;-)

I also recall that there were problems and not what the
problems were. It might be that MS has fixed them.

Frank

[Frank P. Westlake]

On 2012-10-03 08:30, Cesar Romani claimed:

> I'd like to remove recursively all files of size zero.

Set "target=C:\yourChoice"
Set "spec=*"
ForFiles /s /p "%target%" /m %spec% /C "CMD /C if @fsize==0 ERASE /Q
@file"

Frank

[Liviu]

"foxidrive" wrote...

> On Saturday 06/10/2012 14:41, Liviu wrote:
>>
>> Seriously, I'd be curious about any specifics, if somebody
>> remembered.
>
> Yes, I recall one issue. It was when specifying a starting directory
> and it has long filename elements.
>
> I don't have an example, and know that it only goes belly up on
> some combinations.

Thanks for the hint. I'll keep an eye open.

Liviu

[Liviu]

"Liviu" <lab...@gmail.c0m> wrote...

>
> I'd be curious about any specifics, if somebody remembered.

Thanks for all replies. In the meantime I've run some searches on
my own. Haven't found definitive proof of a killer bug, but here's
a few pointers to FOR/D/R behaviors one could call questionable.
Any further findings or insight appreciated.

1.
http://groups.google.com/group/alt.msdos.batch.nt/msg/3129991ba99e2f1b
"Ok, so after more testing there are multiple bugs present with /R.
(1)Enumeration of pathspec only regardless of (filename) specification.
(Whatever is inside the () is passed along with the path.)
(2)It only returns actual filespecs if a wildcard is used with
filename."

Both are in fact due to the same rule (2): an item in the control
section of a FOR loop is expanded to one or multiple matches against
actual files/directories _only_ if it contains a wildcard, otherwise it
is passed literally.

This rule may not be obvious upfront, and is not well documented in the
FOR help. Yet, it's been certainly known and used for a long time. For
example, that's what allows the following to quickly cleanup a few
unwanted types.

for %v in (tmp bak log) do del /q *.%v

If the literal tmp, bak, log were to be matched against existing files,
instead, the above would (almost) never work. Still, variations of that
construct are pretty commonplace. IMHO, this is not a bug.

2.
http://blogs.msdn.com/b/oldnewthing/archive/2007/05/11/2532913.aspx#2549194
"Might as well mention "for /r /d %I in (.) do @echo %I" as well, which
seems to be the method that whoever wrote the help text for the for
command recommends. You get names that end in \., but it lists
directories that (*) misses."

The first part about (.) is correct and, indeed, recommended. The note
about (*) missing directories is rather vague. It might refer to the
fact that "FOR /D /R %d in (*)" skips over the current directory, and
also any hidden subdirectories, while "FOR /D /R %d in (.)" includes the
"." current directory and all subdirectories regardless of attributes.
While an undocumented quirk, don't know that I'd call it a bug per se.

3.
http://stackoverflow.com/questions/8366864/windows-7-batch-script-for-command-error-bug
"There seems to be a bug with the Windows 7 batch file 'for' command.
This command can walk through a source directory and return one filename
at a time. But I found that if my command modify the files in that
source directory the 'for' command could invoke the do command with the
same file name more than 1 times."

I was not able to reproduce that in Win7 Sp1. One thing I noticed is
that the OP had the FOR/R loop return the files in some out-of-sequence
order. On an NTFS drive, they would be returned alphabetically by
default. Maybe the issue is file-system related, in which case it can't
be really tested without more information about the exact environment.
Regardless, if the body of the loop does modify the files/directories
that the FOR acts upon, I can see potential problems occurring.

4.
http://groups.google.com/group/alt.msdos.batch.nt/msg/0f309417184042ec

"Yes, I recall one issue. It was when specifying a starting directory
and it has long filename elements. I don't have an example, and know
that it only goes belly up on some combinations."

Ran a few tests, negative so far.

Liviu

[Liviu]

"billious" wrote...

> On 6/10/2012 12:41, Liviu wrote:
>>
>> Downside of the DIR command in a FOR/F loop is that it fails

>> on names with characters outside the current codepage. [...]

>> FOR/D/R loops handle such "international" names just fine.
>

> I believe we're really getting to the outer limits of applicability of
> a language that was originally designed for the English-speaking
> cognescenti to use.

I don't expect the batch language to undergo spectacular changes
anytime soon. That said, it's far from dying yet, let alone dead.
For one example, the latest 2008 R2 Core is essentially a barebones
server edition of Win7 which boots to a cmd prompt - no GUI, no .NET,
no powershell. If only for the sake of such, I'd guess cmd is not on
Microsoft's endangered list in the foreseeable future.

As for international support, the NT line of cmd has always been
all Unicode internally. Environment variables, string operations, for
loops all handle Unicode just fine. What's still lacking is support
for it at the i/o boundaries - the batch file itself must be 8 bit text,
piping forces a conversion to narrow characters, command output
used in a for loop is also down-converted. Maybe one day those
(mostly artificial IMHO) limitations might be removed. Until then,
still, there is plenty of builtin Unicode enabled functionality
available to take advantage of.

> We now have different editions of different releases in different
> languages, code pages, service packs, privilege levels and seemingly a
> thousand and one other complicating factors - compounded by an
> unprofessional language-maintenance regime apparently run to implement
> half-baked changes at random. Naturally, all this is silently modified
> in the background by seemingly-daily patches that may or may not be
> applied, succeed or fix any problem that may have been encountered.

Can agree with the general sentiment ;-) yet, among all that chaos,
batch language has been remarkably stable compared to others in Windows.

Liviu

[Dr J R Stockton]

In alt.msdos.batch.nt message <506fb69f$0$1721$c3e8da3$dbd...@news.astr
aweb.com>, Fri, 5 Oct 2012 23:41:34, Liviu <lab...@gmail.c0m> posted:

>
>Downside of the DIR command in a FOR/F loop is that it fails on names
>with characters outside the current codepage. This is not a limitation
>of DIR itself, but of the FOR/F loop which converts the output of any
>given command (from unicode) to the current codepage before tokenizing.
>In contrast, FOR/D/R loops handle such "international" names just fine.
>

Program SEAKFYLE should be able to do it.
See <http://www.merlyn.demon.co.uk/programs/32-bit/seakfyle.htm>.
Uses command-line WSH, or runs in an HTA.

Test VERY carefully.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links.
PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.

[Liviu]

"Dr J R Stockton" wrote...
> Liviu posted:

>>
>>Downside of the DIR command in a FOR/F loop is that it fails on names
>>with characters outside the current codepage. This is not a limitation
>>of DIR itself, but of the FOR/F loop which converts the output of any
>>given command (from unicode) to the current codepage before
>>tokenizing. In contrast, FOR/D/R loops handle such "international"
>>names just fine.
>
> Program SEAKFYLE should be able to do it.
> See <http://www.merlyn.demon.co.uk/programs/32-bit/seakfyle.htm>.
> Uses command-line WSH, or runs in an HTA.

Thanks for the pointer. However, as much as SEAKFYLE may be a better
more clever DIR on its own, it will fare no better in a FOR/F loop or a
piped command as far as Unicode is concerned. Like I said, the
limitation there is not with the command, be it DIR or SEAKFYLE, but
with the way CMD itself handles FOR/F and piped commands.

Liviu

[Dr J R Stockton]

In alt.msdos.batch.nt message <5072577f$0$30683$c3e8da3$14a0...@news.as
traweb.com>, Sun, 7 Oct 2012 23:32:29, Liviu <lab...@gmail.c0m> posted:

I was not suggesting putting it in a FOR loop. If there is a problem
with weird names, it can be told to use the traditional 8.3 names. It
could also in principle be recoded to do deletes without using the names
at all.


--
(c) John Stockton, nr London UK. Mail, see homepage. DOS 3.3, 6.20; WinXP, 7.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.

[Liviu]

"Dr J R Stockton" wrote...
> Liviu <lab...@gmail.c0m> posted:
>>"Dr J R Stockton" wrote...
>>> Liviu posted:
>>>>
>>>>Downside of the DIR command in a FOR/F loop is that it fails on
>>>>names with characters outside the current codepage. This is not a
>>>>limitation of DIR itself, but of the FOR/F loop which converts the
>>>>output of any given command (from unicode) to the current codepage
>>>>before tokenizing. In contrast, FOR/D/R loops handle such
>>>>"international" names just fine.
>>>
>>> Program SEAKFYLE should be able to do it.
>>> See <http://www.merlyn.demon.co.uk/programs/32-bit/seakfyle.htm>.
>>> Uses command-line WSH, or runs in an HTA.
>>
>>Thanks for the pointer. However, as much as SEAKFYLE may be a better
>>more clever DIR on its own, it will fare no better in a FOR/F loop or
>>a piped command as far as Unicode is concerned. Like I said, the
>>limitation there is not with the command, be it DIR or SEAKFYLE, but
>>with the way CMD itself handles FOR/F and piped commands.
>
> I was not suggesting putting it in a FOR loop. If there is a problem
> with weird names, it can be told to use the traditional 8.3 names. It
> could also in principle be recoded to do deletes without using the
> names at all.

Well, you appeared to be replying to my post, on a tangent sub-thread
which was precisely about handling Unicode characters in FOR loops.
SEAKFYLE (or any other program, for that matter) does not hold any
advantage over DIR there (again, as far as Unicode is concerned).

Liviu

[Dr J R Stockton]

In alt.msdos.batch.nt message <5074d2d9$0$31215$c3e8da3$3a1a...@news.as
traweb.com>, Tue, 9 Oct 2012 20:43:24, Liviu <lab...@gmail.c0m> posted:

Indeed. But SEAKFYLE, by using CMD.EXE, can delete the zero-byte files
without other aid; or, if preferred, it can list their full paths, for
inspection to be followed by deletion using that list.

And, if wished, it should be able to restrict its work to files last
created/modified/accessed on a Tuesday.