Question about IFileSystemImage

Optical Platform Discussion

William Lin

Hello,

I'm using IFileSystemImage to do some data burning, and I need you guys help here~

here are my questions:

1. After importing data from previous session by ImportFileSystem() or adding some files, is there any way to reset the IFileSystemImage Do I have to release current one and re-create a new instance if I want to restart the creation of image

2. I found that after AddFile() of IFsiDirectoryItem, it seems a temp file would be created at tmep path for generation of CreateResultImage. For example, I add in a 200 MB file by AddFile() then a 200 MB tmp file would come out in my temp path. I want to know when will this temp file be deleted Is there any way to manual clean up this temp file Even after I release the IFileSystemImage instance, the tmp file is still there...

3. The last one,,, I find that I would get E_UNEXPECTED from write() of IDiscFormat2Data when I pass the IStream pointer from IFileSystemImageResult::get_ImageStream. This issue would occur if I have burnt a data disc by IFileSystemImage before ( and yes, the previous temp files are still there). I'm not sure if it's the problem of IFileSystemImage or my calling sequence. Please kindly help check if you guys have this problem too.

Very thanks for any help !
Top

Re: Optical Platform Discussion Question about IFileSystemImage

Henry Gabryjelski - MSFT

1. Absolutely. First thing you want to do is call 'changePoint = get_ChangePoint()'. Later, you can revert the image to this point by calling RollbackToChangePoint(changePoint). Note, however, that once you call CreateResultImage(), the FSI object becomes read-only and cannot be rolled back. If you add in the computational complexity, and the possibility of bugs (it's a non-trivial code path), the best recommendation is to simply create a new FSI object.

2. The temp files are created with the following flags to CreateFile():

Code Snippet

FILE_ATTRIBUTE_TEMPORARY // Flag as temporary file
| FILE_ATTRIBUTE_NOT_CONTENT_INDEXED // Don't index the file (search)
| FILE_FLAG_DELETE_ON_CLOSE, // Ensure file is deleted

Thus, the only reason the file would continue to exist is because of a reference to it. This is typically caused by a refcount leak to the FSI object. Debugging COM ref count leaks is a very in-depth topic which is outside the scope of this forum.

3. (This is just conjecture) If you want to use the resulting IStream more than once, please make sure that you reset the file pointer by Seek()'ing back to the start of the stream. Please let us know if this allows you to burn multiple copies. BTW, I'm not entirely sure I understand the full sequence of your calls. I presumed it was something like:

Code Snippet

// no, this won't compile. :)

CComPtr<IStream> stream = FSI->get_ImageStream();

IDF2Data->Write( stream );

// replace media here...

// ADD: stream->Seek(0);

IDF2Data->Write( stream );

If this is not the general sequence, and the Seek() workaround doesn't help, please give more details on the sequence in your next post so we can consider it more thoroughly.

hth,





Top

Re: Optical Platform Discussion Question about IFileSystemImage

William Lin

Hi,

1. Thanks for your suggestion. I would try to use get_ChangePoint() in my function. Smile

2. After my test, I find that indeed it's a reference count problem. My FSI object (and temp files) could be released correctly if I'm burning on a blank disc.

My problem is that after importing previous session by put_MultisessionInterfaces(), the reference count of FSI object seems to be increased!!!

I have to call FSI->Release() several times to clean up the temp files... I don't expect the count to be increased by the following code:

Code Snippet

hr = m_pDrive->GetDriveCtrlInterface(__uuidof(IDiscFormat2Data), (void**)&dataWriter);
hr = dataWriter->get_MediaHeuristicallyBlank(&isBlank);

if( isBlank)
break;

hr = dataWriter->get_MultisessionInterfaces(&multiSession);
hr = m_pFSImage->put_MultisessionInterfaces(multiSession);
 hr = m_pFSImage->ImportFileSystem(&fileSystems);

3. No, my case is not to use the "same" generated IStream more than once.

My case is like "go through the entire burn process twice". Re-create all necessary interfaces to do the data burning again.

I have tried to seek() before write, but it didn't work... Hope you could find any clue why I would get error code at second burn.

The following is my sequence example, the first round is perfect but I get error at second round:

Code Snippet

while(1)

{

// 1. Insert a blank disc

// 2. Create all needed interfaces. Like IFileSystemImage, IDiscFormat2Data...

hr = CoCreateInstance(__uuidof(MsftFileSystemImage) ,//CLSID_MsftFileSystemImage,
NULL, CLSCTX_ALL,
__uuidof(IFileSystemImage),
(void **)&m_pImage
);

hr = m_pImage->get_Root( &m_pRoot);

...

// 3. Add some files into image by IFsiDirectoryItem

// 4. Burn

m_pDiscFmt2->put_ClientName(appName);

m_pDiscFmt2->get_FreeSectorsOnMedia(&freeBlocks);

m_pImage->put_FreeMediaBlocks(freeBlocks);

m_pImage->put_VolumeName(volName);

m_pImage->CreateResultImage(&m_pImageResult);

m_pImageResult->get_ImageStream(&dataStream);

hr = m_pDiscFmt2->Write(dataStream);

// At the 2nd round,Write()would return E_UNEXPECTED!!

// 5. Release all interfaces...

HELPER_RELEASE(dataStream);
HELPER_RELEASE(m_pImageResult);

HELPER_RELEASE(m_pRoot);

HELPER_RELEASE(m_pImage);

...

// 6. Eject the disc and Go back to the start.

}


Top

Re: Optical Platform Discussion Question about IFileSystemImage

William Lin

Hi, Henry,

About the 3rd question, I think I found the solution!! Big Smile

I found that I always used the same IDiscFormat2Data interface pointer... Stick out tongue

After re-create the IDiscFormat2Data instance, I could burn multi-pass successfully !! Thanks God!

So one IDiscFormat2Data instance could be used only "once" for image recording

About the 2nd question, I'm trying to figure it out.

If you could, please kindly provide the possible functions that might increase the reference count of IFileSystemImage.

Great thanks!




Top

Re: Optical Platform Discussion Question about IFileSystemImage

Garrett - MSFT

Hello William,

For the third question, yes, you found the right answer in the other thread! It was not MEANT to have this limitation and we hope to fix it up for future use...however it is too early to comment on when/how a fix for this would be released :-)

For the second question, I'll investigate if I can reproduce the issue over here and get back to you....

thanks for your patience!

Garrett Jacobson

SDE, Optical Platform Group





Top

Re: Optical Platform Discussion Question about IFileSystemImage

Garrett - MSFT

Hello William,

As for the second question, I could not reproduce any of those functions incrementing the reference count of the IFileSystemImage object.

However while stepping through some sample code, the one thing I did notice that increment the reference count of the IFileSystemImage object is get_Root(). Are you sure that you are cleaning up your references to the root object properly If that was still hanging on to a reference, it would cause the object to not get destroyed...

please let me know if this fixes your issue!

thanks,

Garrett Jacobson

SDE, Optical Platform Group





Top