Invalid file properties returned by dir

So, I've been using dir to quickly get me a catalogue of all the file sizes of a specific type of file. My code works, however, there is one particular file, which returns into the output:

   name: 'dagkgjkajk.his'
   date: ''
  bytes: []
  isdir: 0
datenum: []

Does anyone know why this may be the case?

[Azzi Abdelmalek]

post your code

[Iain]

 b = dir(fold{d}); %fold{d} is a valid folder name. 
 for i = 3:numel(b)
  if b(i).isdir
   fold{end+1} = [fold{d} '\' b(i).name];
  else
   if numel(b(i).name)>2
    if strcmpi(b(i).name(end-2:end),'HIS')
     c(end+1) = b(i);
     sizes(end+1) = b(i).bytes;
    end
   end
  end
 end

The code falls over on this line: "sizes(end+1) = b(i).bytes;", after finding several thousand correct files... It falls over as b(i).bytes is empty. I want to know why it is empty

[Walter Roberson]

Are you able to see the file in the Microsoft File Explorer?

[Walter Roberson]

Iain, is the file system mounted over a network, or is it a local disk?

[Walter Roberson]

Which version of MATLAB is being used?

[dpb]

I'd wonder what the OS dir command returns directly at command line just to ensure it's not an anomaly in the Matlab dir function.

Presuming they're consistent it reverts to how the file was created -- in a Matlab process gone bad or somehow else as to try to pin blame on Matlab or somewhere/somebody else.

[Walter Roberson]

WIth some earlier MS Windows versions you might perhaps run out of directory handles.

[Cedric]

And

 dos('dir dagkgjkajk.his')

returns an information which makes sense (size,date,name)?

[Iain]

OS: Win XP SP3, running matlab 2011b

The file is on a network drive. The other files in the folder contain real details.

The file was generated by test equipment, and the contents are seemingly good. The file was copied from one machine, to a massive storage area (non-networked), then copied to a networked area.

Windows explorer tells me the size and date correctly.

 dos('dir dagkgjkajk.his') % returns the filename, file date and the file size.

The file name length (with path) is only 220 characters.

[dpb]

dos('dir ...returns the filename, file date and the file size...

Yet

d=dir('dagkgjkajk.his');
d.size

returns empty field(s) even called explicitly over the same access path?

That seems somewhat bizarre but then makes me wonder if there's an embedded null or somesuch other funky thing inside one field of the directory information.

Can you try coding a direct call of the WinAPI and then look at the return structure contents in depth?

Given the description of the process by which the present file came into existence it would seem the two likely candidates for the screwup would be the instrument itself or the transfer to the networked device had a hiccup altho certainly couldn't rule out other points along the way entirely...

[Iain]

When my working directory is the same one as that file:

 d = dir('*.his') does return those file parameters as non-empty.

When it is NOT that folder, and I use dir('J:\....\*.his'), it is returned as empty.

[dpb]

And this does not happen for any other file in the same directory w/ the same access paths, correct?

What if you use the fully-qualified name for this file specifically under the same permutations?

If so, it seems to me it makes the idea of there being hidden character or somesuch anomaly specifically in the information on that one file.

I don't suppose you have a different version of Matlab installed as well to make it convenient to try a second version there to see if can isolate one of Jan's "magic strings" kind of bug in dir()...

Oh, just a thought--what does the string 'J:\....\*.his' expand to for the bogus file info? Does that end up w/ a control character that could somehow be being interpreted incorrectly? I forget for certain, will Win let you try '/' instead of '\' for separators?

[Iain]

Ok, now, I'm REALLY confused. It has stopped doing it.

I can only assume that there is some jiggery-pokery going on behind the scenes by our IT guys.

[dpb]

Ok, now, I'm REALLY confused. It has stopped doing it.

Ain't science wonderful!!??? :)

Doncha' just love it when these unexplainable anomalies occur? I'd guess that's as good an explanation as will ever come up with although there was a full moon the other night; that could well have had something to do with it as well...

Keep us posted if it comes/goes again and if there is any resolution other than the aforementioned "Stuff happens..."

Answer 1

[dpb]

... why it is empty

That's up to whatever created it and/or left it that way.

Likely candidate would be an open w/ write permission subsequently closed w/o rewriting anything...

>> type fixed.dat
-1.6999E-3-1.3266E-3 1.2916E-3 3.5491E-4 1.1022E-3-9.5555E-4-3.9528E-4 3.5200E-4
>> fid=fopen('fixed.dat','w');
>> fid=fclose(fid);
>> d=dir('fixed.dat')
d = 
     name: 'fixed.dat'
     date: '23-Aug-2013 07:51:02'
    bytes: 0
    isdir: 0
  datenum: 7.3547e+05
>>

Note an existing file has been truncated. That yours has no creation date means it quite probably was an open of a previously non-existing file followed perhaps by an aborted operation before anything was written. For whatever reason, it was created by the file system but nothing is in it.

The problem isn't so much the file as the code that assumes there won't be such a thing existent--use try...catch block or an explicit test or somesuch to handle it cleanly.

[Walter Roberson]

POSIX compliant systems are not supposed to be able to produce files with no date.

[dpb]

Whoever said Winders was POSIX-compliant? :)

But is that so even under error conditions or the above "open for write"? One can't truncate a file on purpose then?

I was "underneath the impression" (as a former colleague was wont to say) the truncation as above was pretty much universal behavior but I've not used anything much other than PC compatibles since mainframe days or such things as HP=RTE and similar so can't really say have any experience at all other than MS that's pertinent any more.

[Walter Roberson]

Truncating the file contents is fine, but notice that the date itself is empty, and that "bytes" is not 0 but instead []. Such things are not supposed to be possible.

Windows has been POSIX compliant since Windows XP SP3.

[dpb]

You're right, I noted the empty date but whiffed on the size being empty instead of zero--my bad, sorry.

I'd guess a failure occurred somewhere. "Stuff happens..." Maybe a network access went away at the critical moment or somesuch--I'd guess it'll not be possible to determine the actual "why" of the root cause at least w/o some detailed digging into it at the OPs site.