FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Wed Jul 28, 2021 15:29



Post new topic Reply to topic  [ 11 posts ] 
question about ntfs_mst_post/pre_write_fixup 
Author Message

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post question about ntfs_mst_post/pre_write_fixup
Hi,

I meet a problem when porting to ntfs-3g(version 20110412) to my platform.
And I found it is caused by ntfs_mst_pre_write_fixup and ntfs_mst_post_write_fixup in ntfs_attr_pwrite.

ex. if I create a new file gg.log in root dir, the ntfs_attr_mst_pwrite function is called to write buffer back to disk.
This function call ntfs_mst_pre_write_fixup before ntfs_attr_pwrite (the real write function to disk) and later call ntfs_mst_post_write_fixup to fix data in memory.

But I found winXP can not parse the root dir as I expected.
winXP only list the files which are present before gg.log in the root dir, and can not list the files after gg.log.

It seems like that XP do not fix up the data using usa in NTFS_RECORD as the ntfs-3g project do when reading.
ntfs-3g project calls ntfs_mst_post_read_fixup when reading, so it won't cause data coherence problem.

Is my understanding right?
What should I do to meet winXP requirement?

Thanks.


Attachments:
root.GIF
root.GIF [ 171.88 KiB | Viewed 19286 times ]
Thu Jan 05, 2012 11:26
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: question about ntfs_mst_post/pre_write_fixup
Hi,

Quote:
This function call ntfs_mst_pre_write_fixup before ntfs_attr_pwrite (the real write function to disk) and later call ntfs_mst_post_write_fixup to fix data in memory

This is done on several metadata files to ensure the sector is entirely written : the last couple of bytes of each sector in a data block are incremented and must match a value located at the beginning of the block. The value is checked when reading, then it is replaced by the original value.
Quote:
It seems like that XP do not fix up the data using usa in NTFS_RECORD as the ntfs-3g project do when reading.

The ntfs-3g project has a long experience about compatibility with XP. I would be surprised if the fixups were wrong in recent releases, and I would rather suspect your adaptations.

In your hex dump, you point at a fixup at offset 0x796, this does not look like an end of sector, even when assuming the initial offset 0x638 is the beginning of the sector.

I suggest you create the same file with XP and compare the results.

Regards

Jean-Pierre


Thu Jan 05, 2012 12:04
Profile

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post Re: question about ntfs_mst_post/pre_write_fixup
jpa wrote:
Hi,

Quote:
It seems like that XP do not fix up the data using usa in NTFS_RECORD as the ntfs-3g project do when reading.

The ntfs-3g project has a long experience about compatibility with XP. I would be surprised if the fixups were wrong in recent releases, and I would rather suspect your adaptations.

In your hex dump, you point at a fixup at offset 0x796, this does not look like an end of sector, even when assuming the initial offset 0x638 is the beginning of the sector.

I suggest you create the same file with XP and compare the results.


Thanks for your reply, jean.

Er, 0x0 is the beginning of the root in the hex dump.
The offset at 0x796 is because the new index entry is inserted in the middle of the root entry (I think this is the native designed of ntfs-3g project, but I will check with the result of doing the same action in XP), thus 0x7fe - 0x68 = 0x796.

In my porting, I call ntfs_fuse_create_file directly, so it should not have different flow with the native design.
Anyway, I will check this also.

Thanks again.


Fri Jan 06, 2012 04:15
Profile

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post Re: question about ntfs_mst_post/pre_write_fixup
Hi Jean,

After recheck the compare result, I think I was wrong.
The reason why XP did not recognize the files is not due to the picture showed above, the difference at offset 0x796.
The real reason I think is du to the strange change at old offset 0x7FE (new offset 0x866), the file name.
I will check this.

Thanks again.

Regards,
Ryan


Fri Jan 06, 2012 04:53
Profile

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post Re: question about ntfs_mst_post/pre_write_fixup
add picture


Attachments:
root_2.GIF
root_2.GIF [ 104.34 KiB | Viewed 19249 times ]
Fri Jan 06, 2012 07:26
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: question about ntfs_mst_post/pre_write_fixup
Hi,

Quote:
The real reason I think is du to the strange change at old offset 0x7FE (new offset 0x866), the file name.

0x7fe is the end of a sector, this is the place where the fixup should be.

Regards

Jean-Pierre


Fri Jan 06, 2012 09:19
Profile

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post Re: question about ntfs_mst_post/pre_write_fixup
Thanks, Jean.

Yes, the problem is not caused by the data at 0x7fe.

I find it is caused by the definition of member file_name[0] of struct FILE_NAME_ATTR, I have to change the definition to file_name[1] to avoid compilation error by visual studio.
reparse.c(130) : error C2229: struct '<unnamed-tag>' has an illegal zero-sized array

But I do not replace the code where sizeof(FILE_NAME_ATTR) to (sizeof(FILE_NAME_ATTR) - sizeof(ntfschar)).
After doing the modification, the files (including the newly added file) can be recognized by XP.

But, still, I am curious about why other struct such as DATA_ATTR using data[0] member and BITMAP_ATTR using bitmap[0] do not cause compilation errors.

Thanks.
Ryan


Fri Jan 06, 2012 10:41
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: question about ntfs_mst_post/pre_write_fixup
Hi,


Quote:
I find it is caused by the definition of member file_name[0] of struct FILE_NAME_ATTR, I have to change the definition to file_name[1] to avoid compilation error by visual studio.
reparse.c(130) : error C2229: struct '<unnamed-tag>' has an illegal zero-sized array

Microsoft dialect : see http://msdn.microsoft.com/en-us/library ... 2d(v=vs.80).aspx

Maybe because FILE_NAME_ATTR is included in INDEX_ENTRY and not the last element....

Regards

Jean-Pierre


Fri Jan 06, 2012 22:27
Profile

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post Re: question about ntfs_mst_post/pre_write_fixup
Thanks, Jean.

The error happened in the definition of
struct {
FILE_NAME_ATTR attr;
ntfschar file_name[NTFS_MAX_NAME_LEN + 1];
} find;
in function ntfs_fix_file_name, for the realization of Variable-length arrays.

So, the member file_name won't be the last member of the structure.

It seems that the appropriate modification is to keep the file_name length to 1 in FILE_NAME_ATTR,
and change the length of file_name in struct find from "NTFS_MAX_NAME_LEN + 1" to NTFS_MAX_NAME_LEN.
Meanwhile, replace sizeof(FILE_NAME_ATTR) to sizeof(FILE_NAME_ATTR)-sizeof(ntfschar).

Do you have other suggestion?
Thanks.

Regards,
Ryan


Mon Jan 09, 2012 04:49
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: question about ntfs_mst_post/pre_write_fixup
Hi,

Quote:
in function ntfs_fix_file_name, for the realization of Variable-length arrays.
So, the member file_name won't be the last member of the structure.

I see.

The purpose of this file_name is just to reserve space for the file name within the FILE_NAME_ATTR structure.
Quote:
It seems that the appropriate modification is to keep the file_name length to 1 in FILE_NAME_ATTR,

I would not do that, because FILE_NAME_ATTR is used in multiple places, and it would be difficult to get it right.
Quote:
Do you have other suggestion?

I would rather allocate dynamically the "find" struct. This would limit the consequences to a single function.

Regards

Jean-Pierre


Mon Jan 09, 2012 09:27
Profile

Joined: Wed Nov 23, 2011 09:11
Posts: 35
Post Re: question about ntfs_mst_post/pre_write_fixup
I get your point.
Thanks for your suggestion, Jean.


Mon Jan 09, 2012 11:02
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.