EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Disk is not formatted error when using CallbackFS

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
#6655
Posted: 06/17/2008 10:13:02
by Brad O'Hearne (Standard support level)
Joined: 03/16/2007
Posts: 12

This issue regarding allocation size and the file system name is not in the documentation for the SetFileSystemName() function. This leads me to believe that how this file system name is set determines how Windows handles the file system implementation. What behavior is different based on the file system name? What if I set the name to FAT, vs. NTFS, vs. BRADS_FS (i.e. something I just made up). What are the ramifications of doing each? If allocation size was the only issue, then I'd be inclined to make up my own name so that I could just set the allocation size equal to the end of file, like in the CBFS sample apps. But if I'm potentially affecting performance, or some other aspect of file system handling, I'd rather not do this.

What's the best route?
#6656
Posted: 06/17/2008 10:48:57
by Eugene Mayevski (EldoS Corp.)

Please direct this kin of questions to Microsoft. We don't write the OS kernel. In brief, all Callback File System does is take the file system request and after certain processing passes it to your user-mode code. Of course, there are some other under the hood things being done, but your quetions are not applicable to CBFS at all.


Sincerely yours
Eugene Mayevski
#6658
Posted: 06/17/2008 11:21:55
by Brad O'Hearne (Standard support level)
Joined: 03/16/2007
Posts: 12

Eugene,

Quote
Please direct this kin of questions to Microsoft. We don't write the OS kernel. In brief, all Callback File System does is take the file system request and after certain processing passes it to your user-mode code. Of course, there are some other under the hood things being done, but your quetions are not applicable to CBFS at all.


This response is inappropriate on three levels:

1) It is entirely analog to the problem in the thread, as you yourself introduced the issue of the file name as being relevant to the operation of the windows kernel / file system with respect to allocation size, in direct contradiction to a response prior by Vladimir, an Eldos developer. If you are going to introduce the issue of file system name as a detail relevant to the behavior of the file system, then it is inappropriate to give a client the "don't ask that question here" response.

2) The Eldos samples that ship with the file system, and the answers to previous support tickets I have posted have been received answers about setting allocation size contrary to your claims. Therefore, it is entirely appropriate for me to be probing further regarding the answer.

3) This is not the first time I've received a "go elsewhere with your inquiries" response to questions of mine about CBFS. While I understand that something as complex as the windows kernel is very difficult, if not impossible to completely obfuscate, you are selling and supporting an API. Therefore, OS concerns are your issue, not your API user's issue, with respect to understanding how your API works. Please do not resent users for asking questions -- the reason they are doing so is because they are using your product. If an answer to a question is determined by a particular behavior of the file system, then communicate that. But don't do the RTFM thing -- that isn't becoming of a relationship between a vendor and a client.

You were the one who introduced a new variable into the allocation size mix with the file system name. The CBFS documentation is extremely light, and there's no way a user of your API is going to know the answers to things like this without directing questions to your organization.

Please, let's keep the dialog constructive.

Thanks,

Brad
#6659
Posted: 06/17/2008 11:40:40
by Eugene Mayevski (EldoS Corp.)

The questions about how the OS behaves should be addressed to it's developers, i.e. Microsoft. We are not Microsoft support. We can answer the question how Callback File System will behave. We have neither source code nor internal documentation of Microsoft to be able to answer your question about how the OS will behave in this or hat scenario. We can only warn you about possible consequences.


Sincerely yours
Eugene Mayevski
#6660
Posted: 06/17/2008 12:38:13
by Brad O'Hearne (Standard support level)
Joined: 03/16/2007
Posts: 12

You are missing the point. Perhaps this will shed a little light on the situation a user of the CBFS API is in: can you please product an exhaustive document which accurately delineates across the entire CBFS API which issues are Microsoft-only issues, which issues are Microsoft issues but that have dependence on the implementation choices in the CBFS source code, and which issues are exclusively contained to the CBFS API source code?

If you can't answer this, then how in the world do you expect a customer to inherently know the answer to it, and then once it has been established that a question needs to be directed to Microsoft, that the customer can adequately speak to Microsoft and communicate the context and intent of the methods used in the CBFS source code?
#6661
Posted: 06/17/2008 12:57:42
by Eugene Mayevski (EldoS Corp.)

File system driver development is almost completely undocumented. We don't have a list of "issues" that may happen. As for how to ask Microsoft correctly about the allocation size, Vladimir will give you this information.

I would offer that IF you use file system name to be FAT, FAT32 or NTFS, then report allocation sizes to be the multiple of 512 bytes and forget about this question completely. Having a curious mind is good sometimes, but if you want to spend time on this highly theoretical question, you really should ask Microsoft.


Sincerely yours
Eugene Mayevski
#6662
Posted: 06/17/2008 13:14:52
by Brad O'Hearne (Standard support level)
Joined: 03/16/2007
Posts: 12

As for it being "highly theoretical", or due to curiosity, the whole tenor of this conversation is just going from bad to worse. I didn't raise the file system name question, you did, with potential REAL ramifications to behavior, not theoretical ones. And I'm not asking due to curiosity, I'm asking because I don't like having support tickets with answers on allocation size contrary to what you are telling me now, and having built our file system according to this direction, I don't like knowing I may have burned days / weeks debugging issues that may have been impacted by this as a result -- hardly "theoretical".

I'm going to gracefully exit this thread, as the real issue here isn't a technical one. I'm interested in productive dialog, and this has more or less left that domain.
#6663
Posted: 06/17/2008 15:11:06
by Volodymyr Zinin (EldoS Corp.)

Hello,

The following is from the FILE_ALLOCATION_INFORMATION structure description in MSDN:
"A file's allocation size and end-of-file position are independent of each other, with the following exception: The end-of-file position must always be less than or equal to the allocation size."

Please follow this rule and if a problem occurs then we'll fix it.
But sure the "standard" windows file systems (FATFS, NTFS, CDFS, etc.) set allocation size to a value that is multiple of sector. And perhaps some code in the system can expect the same behavior from other file systems. We have already encountered with such types of problems - i.e. MSDN asserts something but some system components expect only the "standard" behavior (the same as the "standard" file systems have). But with the allocation size we've not got any problems yet. So I think that the rule above should be work.

About the file system name - I recommend you to set this parameter to one of the "standard" FS names or leave it as default (it's set to "FAT32").
#6733
Posted: 06/24/2008 12:58:38
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

The original question that this thread was opened for was the message that someone received saying "Disk is not formatted".

I receive this error message also whenever I get an error from my system in the OnEnumerateDirectory callback. In that case I do what the CBFS documentation tells me to do when I get errors, namely I throw a CBFSError with a code that I get from the Winerror.h file. This causes the "Disk not formatted" message to come up. It doesn't seem to matter which code I specify, any code out of Winerror.h causes the same message box to pop up.

It seems like the CBFS code just pops up a generic error MessageBox no matter what error it gets. Is that correct? If so, I can live with that, but it would be nice if the MessageBox was formatted with a message that was more specific to the Winerror.h code that I am sending.

PS, I use the C++ library interface on Windows XP Professional SP2.
#6734
Posted: 06/24/2008 13:08:28
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I just tried throwing the ECBFSError with my own formatted string that depends on the error I get and the MessageBox that pops up still says "Disk not formatted". Again, I can live with this but it seems like a bug.
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.

Reply

Statistics

Topic viewed 23242 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!