Hi Szaka See answers within text.
I will make a new version available next week, do you have any recommendation for using cvs ? Regards Jean-Pierre Szabolcs Szakacsits wrote: > Hi Jean-Pierre, > > On Mon, 24 Sep 2007, [ISO-8859-1] Jean-Pierre Andr� wrote: > > >> Could you spare some time on the following problems : >> > > Sure. And I'm very sorry I still didn't answer your previous email (if all > the issues were trivial then I would have done it long ago ;-) > > >> 1) appending data to $Secure/$SDS (a sparse file). >> > > I have never seen $Secure/$SDS being sparse. This doesn't sound good but it > could be possible and things should still work. > > >> Basically, what I do is >> - increase the stream size (ntfs_attr_truncate()) >> - write at desired location (ntfs_attr_pwrite()) >> > > You could do it simpler (safer) like it's in ntfs_fuse_write() with the > offset set to the end of the file. > > I think I have already done this without success, but I will retry, there might have been other causes. >> The result is roughly as desired, by chkdsk complains : >> - bad record in a sparse file >> > > I would need the full chkdsk log (it's ok in French): > > http://en.wikipedia.org/wiki/Chkdsk#Viewing_results > > When you make changes to the NTFS volume then run chkdsk beforehand because > the Windows NTFS driver sometimes leaves problems behind which you could > think it's your fault but in fact it isn't. > Ok >> - free space marked in use in MFT bitmap >> > > You can safely ignore this. This is also a Microsoft bug: > > http://ntfs-3g.org/support.html#usedfreespace > > >> Notes : >> - chkdsk does not delete useful data in $SDS >> - initialized_size is not modified, whereas Windows >> sets it similar to data_size, but that could be not meaningful >> and chkdsk does not fix it anyway. >> >> 2) getting the next key in an index >> > > Which one do you need: the index by hash or Security ID? > I only need it for index by hash (for checking for hash collisions) but this should be done in a generic way, there is no need to compare keys, just walk in the tree. This would also be useful to return sorted file names in readdir() >> This is needed when checking for collision in index hashes. >> The real problem here is to build a significant multilevel >> index tree, as with security descriptors it is quite difficult >> to generate more than a couple of index nodes. >> I will possibly have to create a test configuration with >> directories, unless the desired code is available somewhere >> and tested.... >> > > Unfortunately I didn't have time to do it yet and it may not be very > trivial. I guess this is urgent for you, right? > Not so urgent, I have a (non-generic) solution, but it is difficult to test (creating a hash collision between keys in different index blocks is not easy) > Btw, could you test if the read-only file creation works now? > Yes, it does. I also implemented the access() method, the default fuse method was not satisfactory. > Thanks! > Szaka > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
