Question 1

I am busy with q1. What is ment by "directory or a fie and sring"?
I understand what the dir should be and the string but what is ment by "file". Should we op a text file to read more one directory in to be searched ????

yeh i also dont get that.

Well my understanding here is the following:

From the question:
Implement a file search utility, in such a way that given a directory or a file and a string, the program will display files and directories whose name contain the string.

So my interpretation is that you provide the program with two parameters.
Parameter 1: a directory of a file
Parameter 2: a string

The program must then search for files or directories that has the specified string in the name of the file or directory only. The example also indicates this. I could not find any reference in the question that indicates that we should search within the files ....

Hope it helps...

I have a question on interpretation. I've been rethinking this question and started wondering about the file sizes aspect.

I understand that we need to display the files that match the search criterion. That's pretty easy to understand but what about the directories? You must display the directory, that's clear but what about the size? Is it the total of all the files and directories inside it or just the size of those that match the criterion?

I considered it so: A directory is a structure to navigate and place files. Size isn't an attribute of a directory. Size is an attribute of a file. The cumulative sizes of the files will give a report on the size of a directory. To implement a size function for both would be redundant.

I think you missed the point of the question. I only determine size in one function regardless of file or directory.

What i want to know is if we add up the file sizes to get the directory size, do we add up all the sizes of the subdirectories and files or just those that match the criterion?

E.g. The searched directory contains five files and two subdirectories. One subdirectory matches the criterion and so do three files. Does the directory size equal the sum of the sizes of all files and subdirectories or just the sum of the sizes of that one subdirectory and the three files?

I think that "directory size", in the singular form, would refer to the size of that directory. That size would be determined by the sum of all its files. That is why I left the size function to the file part.

So the size of a directory is a reporting preference, drawn from file data. If you query directory size on your computer (using dos or whatever), it'll give a report of size per directory which totals all the file sizes.

My reporting is the total sizes of the files picked.

I agree that the question seems to mean directory OR file for the first parameter.

However, I am not that clear what to do if a file is entered. Should the program only seach that filename to see if the string (parameter #2) is contained in it?

By contrast, I understand that if a directory is given then the given directory and all subdirs are to be searched for directory or filenames that contain the string.

Any comments/help would be much appreciated.

R

look at esckay's post higher up, it's like that. it'll work somthing like this:

filesearch search string start directory

example

filesearch assign1 c:\cos311

which should return all files and dirs with assign1 in its name

filesearch assign1.doc c:\cos311

which should obviouly return assign1.doc, note the DOT DOC, (prolly even something like assign1.doc.txt) but definitly NOT assign1.xls or just assign1

that's how i see it.

Thanks, that is very useful. I will try and do a further posting if I can think of better way other than overriding the function...

I've been battling with the example in the text book all day (gonna use that as a basis for my assignment question) it seems that overiding the function isn't that bad... only thing i havn't worked out yet is to process more than 1 file...

i'll post what i have done on the example in a new thread round about 5pm, hopefully there is some code that someone can use...

This question requires that you reuse the existing FileVisitor class provided in the Ezust library. In my solution, I imported the header and class file into my project in the IDE and use the class as the base for my own visitor which simply prints the required information (i.e. filename and size) to the console. To do this, all you need to do is override the processFile(QString) function declared as virtual in the FileVisitor. This function is invoked by the FileVisitor class for each matching file found.

Yes, but how do you handle directories without making changes to the FileVisitor class, because although the processFile function is virtual the processDir is NOT virtual? I think that is the tricky bit.

R

LOL, funny you should ask that. I decided that the only way to handle directories is to do exactly what you proposed so therefore I changed it accordingly and added a note to my assignment explaining the change and reasoning behind it.

maybe i don't understand the question so well but i didn't make any change to the filevisitor class to handle dirs. from what i've seen and done in the textbook example, if you use ./ or ../ or even c:\cos311 as arguments, the filevisitor code goes thru the dirs and sub dirs. get a running total of all files visited and you'll have dir sizes. also QDir is inherited and has a .dirName() method, y not use that... or am i missing something?.

wait, i see what i missed. had a blond moment\black out...

I got fedup with Ezust's libs and rewrote it to my liking. My reasoning was that I'm still using a filevisitor pattern.

Rick - i did the same thing. it makes more sense

haha, found a way to get dirs without having to override processDir().

you just need to get the dir name when you in the dir and mark a bool true if you found it and reset it to false when you in a new dir (this can be done in processFile() method )

So if i understand you correctly, you check whether the filePath() matches the filter strings specified on command line, then set an initially false boolean to true if it matches, and then ? Do you print the directory name if said boolean is true ? doesn't this print duplicate directories ?

It seems the 2 most reasonably ways of doing it without editing the provided filevisitor.{h,cpp} or creating your own, are:
a) override processDir(QString);
b) create a new method: findMatchingDirs(), which takes parameters: path and filter, and returns a QStringList containing names of matching directories which can then be printed.

@nobbie: how would you do (a) without modifying the provided FileVisitor and marking processDir as virtual?

I did the following:

(1) changed the FileVisitor declaration of processDir(QDir& to virtual and then override this in my derived class for directory processing and
(2) changed the implementation of processDir(QDir& in the base class to use the filter when retrieving a list of directories.

For the second item, I realise that it constrains the searching to only finding files in directories that match the search criteria however depending on your interpretation of the question, it could be construed that this is what was required which was my interpretation

To override the processDir() method of the parent class, simply create a new one in the inherited class. It will only be usable within the scope of the inherited class though, ie: if an inherited function calls processDir(), it will use the parent's implementation.

This doesn't make it ideal and kind of obsoletes the whole idea behind the visitor pattern since your re-writing the entire method.

I did the following:
1) print files matching the name filter by overriding processFile(),
2) print directories matching the name filter by writing a completely new method.

It would be interesting to see the model answers.

I originally thought that I would alter the FileVisitor class and make processDir virtual but then the tut letter came and said that this was not allowed. I was upset about this since I'd convinced myself that this was the only way to accomplish the task until I did an entire rethink. I now only do checking in processFile and it all works.

If you follow the logic behind the code you will see that the following happens:

Dir A
 |
 | - SubDirA1
 |    |
 |    |- File 1 (10kb)
 |    |- File 2 (5kb)
 |
 | - SubDirA2
 |    |
 |    |-SubDirA2a
 |    |  |
 |    |  |-File 3 (24kb)
 |      
 | - file 4 (20kb)
 | - file 5 (15kb)

The way the processFile function in FileVisitor steps through the code will be to return File1, File2, File3, File4 and then File5 - in that order.

You can fill in the blanks for the rest. First, you say that Dir A is entered, then SubDirA1 is entered, then the two files are processed, SubDirA1 is exited, SubDirA2 is entered, SubDirA2a is entered, file 3 is processed, SubDirA2a is exited, SubDirA2 is exited, file 4 and file 5 are processed.

You may want to process the directories separately but you don't have to since the heirarchy of directories is preserved in each file processing. By this, I mean that a directory is processed completely before another is processed on the same level.

I used this fact and created two stacks, one for directory names and one for sizes. Everytime I processed a file, I checked the file path and compared that to the directory name at the top of the stack, if it matched, I added that file's size to the size at the top of the sizes stack.

If the directory names did not match, there were two possibilities: either the next file is in a subdirectory, or it was in a parent or sibling directory. This could be determined by comparing the path strings. If I was going into a subdirectory, it's path was added to the top of the stack and a zero size added to the top of the sizes stack. If I was going to a parent directory, I would pop the name and sizes stacks and add that size to the size of the directory above that.

That was my approach.

How did everybody else tackle this who didn't modify the FileVisitor class?