qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understandin


From: Pintu Kumar
Subject: Re: [Qemu-devel] [QEMU : VVFAT] vvfat.c - help required for understanding/modification
Date: Thu, 27 Oct 2011 00:47:38 +0530

Dear Mr. Johannes,

I am sorry but I think you took me wrong. I never asked you to do things for me.
I just wanted few clarifications to proceed further as I was stuck
after performing few experiments as below:

For scanning only top-level directory I used the following approach.
You can refer to this link for the vvfat original code:
http://www.netmite.com/android/mydroid/external/qemu/block-vvfat.c

read_directory(.....)
{
         ---
        while((entry=readdir(dir)))
        {
               ---
               direntry=create_short_and_long_name(s, i,
entry->d_name, is_dot || is_dotdot);

               /* skip sub-directory here */
               if(!is_dot && !is_dotdot && (S_ISDIR(st.st_mode)))
               {
                       free(buffer);
                       s->current_mapping = NULL;
                       break;
               }
               -----
        }
        ----
        -----
}

If I use the above logic I could able to scan only top-level files
with empty sub-directories.
As follows:
# ls -la /mnt/vvfatfs
.
..
File1.txt
File2.txt
test1

But there is one problem here if I use the above logic.
When I issue "ls" command "vvfat_read" is not getting triggered.
So I think there is some problem and I could figure out where to
implement the dynamic scanning of sub-directory later.

But in the above logic if I scan at least the "dot" and "dotdot"
entries for the sub-directories I could get the trigger point in
vvfat_read during "ls" command.
That is if the output of "ls" is as follows:
# ls -la /mnt/vvfatfs
.  <dot for vvfatfs>
.. <dotdot fot vvfatfs>
File1.txt
File2.txt
test1
   .   <dot for test1>
   ..  <dotdot for test1>

I am not sure why this is happening. So I need your help in understanding.

Similarly I implemented dynamic creation of mapping for
sub-directories in "vvfat_read" by remembering the previous mappings
for the sub-directories.
And after that I could able to see to get the modified FAT content.
But the content itself is not visible (except the dot and dotdot
entries) for the sub-directory when we use "ls" command to see them.
I will talk about in detail later once you could confirm the
top-directory only scanning method.

Other comments are in-lined in your mail below.


Thanks,
Pintu


On Sun, Oct 23, 2011 at 12:28 AM, Johannes Schindelin
<address@hidden> wrote:
> Hi Pintu,
>
> On Sat, 22 Oct 2011, Pintu Kumar wrote:
>
>> I already did some work for scanning only top level directory in vvfat.
>> Using the following logic in read_directory()
>>
>> if(parent_index >= 0 & (!dot & !dotdot))
>> {
>>        free(buffer);
>>        break;
>> }
>
> Sorry, this is way too deep in the code (and I'd have to guess because you
> did not grace me with exact locations), I cannot afford to dive into it
> that far. But what I can say is that it is not all that easy; you'll need
> to refactor the code.
>
> You _will_ need to reserve sectors for future directory parsing. You
> _will_ need to add code that intercepts reads to those sectors. You _will_
> have to read the directories in question when those sectors are accessed
> and thereby commit the sectors to a final state.
>
> BTW both Kevin and I said that before.
>
>> Hope this is correct logic for skipping sub-directories content by just
>> scanning only dot and dotdot entries inside it.
>
> It would be, if all you want are empty directories.
>
>> But as per the recent analysis it was observed that there is some
>> problem in skipping sub-directory scanning itself. Because when I issue
>> "df" command on VVFAT partition I get read_cluster errors during these
>> sector location.
>
> When you issue "df", you need to commit to which sectors are reserved. By
> that, you take almost all the advantage of lazy directory parsing away.
>


Actually, after using "df" command on the original code itself, it
give read cluster error.
So, there is something messy here with the original code itself.



>> Mr. Johannes, can you clarify on this first.
>>
>> Then we will look into the dynamic mapping part later.
>
> I am very sorry, but I do get the impression that the intent is to lure me
> into doing all the work, including the investigation what it would take to
> turn the code into a version that reads just the top-level first and only
> later the subdirectories.
>
> This will not happen. I have enough projects that I want to tackle myself,
> and I am extremely unwilling to do the work for somebody else when that
> somebody else is paid to do the work. For the things I _want_ to do I
> already have too little time, given that my day job is quite demanding and
> asks software design and architecture of me already.
>


I think you took me wrong. I am sorry but I never asked you to do it for me.
I just wanted to get some clarification quickly since you are the
author and who else can best explain to me except you.
Right now I myself is not fully convinced if some thing like this is
completely possible and feasible.
I need to perform various experiments and dont want to leave even a
single chance before reaching the conclusion that it is not possible.



> So: you _will_ have to acquaint yourself with the FAT and then the VFAT
> specification. You _will_ have to make a proper plan how the client may be
> fooled into believing that there is a fixed filesystem when there is
> actually just directories of files. And you _will_ have to write that code
> yourself.
>



Yes, I have already tried implementing it myself and I got some amount
of success.
But the moment I am stuck, I came to the mailing list for some
clarifications and help.



> I hope this clarified it?
>
> Ciao,
> Johannes
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]