How to get the size of individual files within a folder by using uigetdir, not by uigetfile ?

Hi all,

I am working on a project and pretty successful till now on that. I would like to enhance my program further. The program is designed to copy a user specified file from the server. Before copying, the program checks whether the server has completely downloaded the file, or if it is still in-process. If it is still downloading, program waits till it is finished (Size info of the file used here) and then copies it to the system.

Now, the next version of my program is expected to work for multiple files within a user specified folder(directory). Imagine, the user selects a folder and specifies a range of files (like 1:10), the program checks each file at a time and copies it to the system.

Problem: The problem i am facing here is - I am not able to check the size of the file within a folder, when the user selects the folder. I have used "uigetdir" here.

Can someone please tell me how can i get the size info of the file, which is in a folder by using uigetdir ?

Answer 1

[Walter Roberson]

folder_name = uigetdir();
if ~ischar(folder_name); error('Canceled out'); nd

foldinfo = dir(folder_name);
foldinfo([foldinfo.isdir]) = [];  %remove subfolders including .. and .
for K = 1 : length(foldinfo);
  thisfilename = fullname(folder_name, foldinfo(K).name);
  thissize = foldinfo(K).bytes;
  fprintf(1, 'File %s is %d bytes big\n', thisfilename, thissize);
end

Note: in general, the size of a file can change when it is copied to a remote system.

• A file transferred in text mode could be a different size because of changes in the line terminator.
• A Windows file transferred in text mode could end up shorter even to a different Windows system because if there is an end-of-file character (control-Z, ascii 26) in the file, the reading program could detect end-of-file at that point and is not required to transfer anything after the EOF.
• A file transferred to a block-structured system such as VM/CMS could have its size rounded up to the next block boundary
• A file transferred from a DEC VMS system might be a file written with RMS (Record Management Services) that might have embedded PATCH records that might get unwound when the file is read out, resulting in a different file size (because it does not need to store the PATCH records)
• Translating between character sets can change file size, especially for character where there is no one-to-one equivalent, such as in going between EBCDIC and ASCII
• A file copied from a filesystem that supports "holey files" (blocks where data has not actually been written so the operating system did not allocate any storage for the area, with undefined content for the middle; or alternately, a filesystem that supports demand-zero pages in the middle of a file that are not actually stored until they are written to but will return definite 0 values when read) may end up a different size on the remote end as the transfer process might not know about the holes and might read-out and store as definite the skipped areas)

Thus, for file transfer, one should not be concentrating overmuch on the file size matching between the two systems: instead, one should be concentrating one's efforts on ensuring that the file transfer protocol is reliable and provides a positive acknowledgement that the file has been completely received and stored. That notification (whether sent or received) is the only thing that one should be basing any action on, not relying on the file size as you could determine that transfer had succeeded just by looking at the size.

Say, that reminds me, I missed the bit about how the file size information might be in different units, such when you are transferring between 36 bit systems and 32 bit systems...

I have personally encountered each of these problems in creating file transfer programs, except for the issue with holey files. (Not that I haven't encountered the occasional holey files, but I never happened to have a reason to deal with them in a file transfer program that I wrote.)

[Kishore]

Thanks for your time. I guess you got my question wrongly. Let me make it simple, I just need to know how access multiple files within directory (by using UIGETDIR) and getting file info(size).

For example:

The user selects a folder and specifies file number 1:10.

Files from 1 to 10 is accessed and size info is obtained.

[Dr. Seis]

So... the user already knows that files "1:10" exist in the user-specified directory? Does the user at any point need to select individual files from within the directory?

[Walter Roberson]

You cannot select multiple files by using uigetdir(). You can select a single directory by using uigetdir(), and then you can use as many files out of that directory as you like. The only change to the code I posted above is to change

for K = 1 : length(foldinfo)

to

for K = 1 : min(NumberToSelect, length(foldinfo))

The code I posted already gets the file size info: I show it being printed out.

There are numerous different ways that you could get the input about the number of files to use. One of the ways would be to use

inputdlg() http://www.mathworks.com/help/techdoc/ref/inputdlg.html

I would suggest that having the user specify the _number_ of files would often be too error prone, as the user would have no control over which files were selected. I would suggest that it would make more sense to use uigetfile() with multiselect turned on in order to allow the user to select the exact set of files to work with.

I do not believe that I got your question wrong. You wrote "If it is still downloading, program waits till it is finished (Size info of the file used here)" and I directly addressed that point, showing why that is a technically flawed procedure. When you post a question, do not be surprised if people inform you of problems in the methods you plan to use.

Oh yes, and for greater certainty: it is not possible to use uigetdir() to get file size information. uigetdir() can *only* return the name of a single folder; it cannot return anything else. You have to use the folder name returned and do the other actions based upon the content of the folder... just the way I already posted the code for.

[Jan]

Walter's answer is matching. +1

I'm convinced, that checking the download status of a file by requesting the file size is not reliable. Too many details can effect the file size. E.g. the downloading tool can reserve the destination at once to limit harddisk fragmentation. Modern browsers copy the data to a file called <filename>.part to avoid confusions. You can habe alternative data streams attach to the file when you operate on NTFS volumes. Etc. Your approach might be successful in 999 of 1000 cases. And in the last case it will create junk without a notice.

Would you use your program, if you do not transfer files but money?