Hi, Bogdan wrote: > Hello everybody. > > I've prepared a small patch for utils.c and ntfswipe.c: > - in utils.c, checking for allocated blocks is fixed to pre-fetch > data on the first run, > - in ntfswipe.c, wiping file tails in enhanced and wiping undelete > data is introduced. >
Please include your patch to ntfswipe.h (adding the field undel) I had difficulties compiling your patch, because it is not portable : static unsigned const int patterns[NPAT] = This is not portable, change to "static const unsigned int" const int NTFS_BUF_SIZE2 = 8192; char buf[NTFS_BUF_SIZE2]; This is not portable, change to a good old "#define" const int NTFS_BUF_SIZE2 = 4096; same, and as this is a different value, an explanation to what both values mean may be useful. a_offset = ((u32) ctx->attr + le16_to_cpu (ctx->attr->value_offset) ); ctx->attr is a pointer, which cannot fit into a u32 on a 64-bit computer, change the u32 to an unsigned char*, and change a_offset accordingly. Also, is this an offset or a pointer ? fill_buffer ( pass, (unsigned char *) a_offset, ctx->attr->value_length, value_length is a le32, it cannot be cast to a size_t, it has to be le32_to_cpu'ed, also the cast to unsigned char* is not needed if a_offset is properly defined. fill_buffer ( pass, (unsigned char *) ctx->attr->value_length, sizeof(u32), What does this mean ? you cannot ever cast an le32 to a pointer. ret = ntfs_rl_pread(vol, na->rl, offset, 2, &block_size); block_size = le16_to_cpu(block_size); This creates confusion, as block_size has a couple of representations. Please use another variable such as : le16 block_size_le; ret = ntfs_rl_pread(vol, na->rl, offset, 2, &block_size_le); block_size = le16_to_cpu(block_size_le); indx_record_size = le32_to_cpu(indx_record_size); Same issue as above. > Additionally, a small correction is added to the layout.h file > (change from floating-point constant to long long), so that there > are no warnings when ntfsck.c is being compiled. You can make this > conditional, there are autoconf tests that check for support of the > "long long" type in the C compiler. > > It would be nice if you could make the "list.h" header a part of > the public API/development package, with "NTFS_" or "ntfs_" prefixes > on the symbols. > > Please reply also to my e-mail address (not only to the list) when > replying to this mail. > > If you can see this mail, then it means you have to subscribe to the > mailing list to be able to post messages (while on your website you > said this list is open). > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > ntfs-3g-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel > -- JP André email [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
