Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsWindows VistaWindows XPWindows MeWindows 98Windows 95Virtual PCInternet ExplorerOutlook ExpressWindows MediaSecurity
Related Topics
MS Server ProductsMS OfficePC HardwareMore Topics ...

Windows Forum / Windows Vista / General Topics / May 2008

Tip: Looking for answers? Try searching our database.

Changes in dir command

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Michael J. Thurgood - 22 May 2008 14:08 GMT
Within the command prompt in Windows Vista, the dir command now shows
non-zero byte counts for folders.  This is a change from prior versions of
Windows such that now, the output from the "dir" command does not match
right-click, Properties from Windows Explorer in terms of total bytes for a
folder (including subfolders).  Is there any way to change the behavior of
the "dir" command to report 0 bytes for folders?
Michael J. Thurgood - 22 May 2008 14:17 GMT
I need to clarify that these differences in the "dir" command appear to occur
when obtaining the directory of a CD or DVD.  Folders still report zero bytes
within "dir" commands run on hard drives or network drives.

> Within the command prompt in Windows Vista, the dir command now shows
> non-zero byte counts for folders.  This is a change from prior versions of
> Windows such that now, the output from the "dir" command does not match
> right-click, Properties from Windows Explorer in terms of total bytes for a
> folder (including subfolders).  Is there any way to change the behavior of
> the "dir" command to report 0 bytes for folders?
Mark L. Ferguson - 22 May 2008 14:52 GMT
You may find a hidden file named desktop.ini in those folders. The autorun
feature writes it.
Signature

Was this helpful? Then click the Ratings button. Voting helps the web
interface.
http://www.microsoft.com/wn3/locales/help/help_en-us.htm#RateAPostAsAnswer
Mark L. Ferguson
.

> I need to clarify that these differences in the "dir" command appear to
> occur
[quoted text clipped - 11 lines]
>> of
>> the "dir" command to report 0 bytes for folders?
Michael J. Thurgood - 22 May 2008 15:04 GMT
I don't think a hidden desktop.ini explains the difference.  I use the
following command to create a directory of archived data on CD / DVD for
later searching:
    dir /w /s /A /OGN > [filename]

I believe using this syntax, all types of files should be included in the
directory output, including system and hidden files.

Here's an example output:
=======================================
Directory of F:\PDF_120605

02/07/2007  01:03 PM    <DIR>          .
02/07/2007  01:03 PM    <DIR>          ..
12/06/2005  05:20 PM           799,804 Figure-1.pdf
              1 File(s)        801,288 bytes
=======================================

Though the folder only has one file, the total bytes for the folder is
larger than the bytes for the file, so bytes for the . and .. folders is
being included.

Here is an example from an empty folder:

=======================================
Directory of F:\Projects\Modeling

02/07/2007  12:45 PM    <DIR>          .
02/07/2007  12:48 PM    <DIR>          ..
              0 File(s)          1,060 bytes
=======================================

> You may find a hidden file named desktop.ini in those folders. The autorun
> feature writes it.
Jim Dell - 23 May 2008 12:32 GMT
> I don't think a hidden desktop.ini explains the difference.  I use the
> following command to create a directory of archived data on CD / DVD for
[quoted text clipped - 30 lines]
>> You may find a hidden file named desktop.ini in those folders. The autorun
>> feature writes it.

I think the space might be for the file system itself.  Record a CD or
DVD with no files on it and see how much space is taken up.

Jim
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.