|
From: Anton A. <ai...@ca...> - 2002-07-07 20:12:49
|
Hi Szaka, At 16:07 07/07/02, Szakacsits Szabolcs wrote: >On Sat, 6 Jul 2002, Anton Altaparmakov wrote: > > get_size_for_mapping_pairs() -> ntfs_get_size_for_mapping_pairs() > >ntfs_mapping_pairs_size() This is nice but there is one problem: we don't know if it determines the size of existing mapping pairs or of the to be created mapping pairs. ntfs_mapping_pairs_size() to me would suggest it is getting the size of the existing mapping pairs, which by the way is a function I want to implement at some point, I think it can be used nicely to optimize the allocation of run lists instead of having to reallocate memory all the time during decompression of the mapping pairs. On second thought, maybe you are right. Then the function I describe above could be called ntfs_run_list_size() to be consistent with the naming scheme. I still think the two names may be misleading but if you think the two names are ok I will switch. Or even feel free to rename it yourself if you like, so you can test if your write access to cvs works properly. (-; > > Why do you need ntfs_rlwrite()? > >It exactly does what I needed. Not more, not less and it was there :) > >It's needed to write out the new updated bitmap pointed to by the >truncated run list of the unamed data attribute of $Bitmap (unusual, >improbable resident attribute case is not yet supported). > > > It is a very ugly, hacked together function > > which I just came up with because it was the quickest way to do what I > > wanted at the time and I was pushed for time when writing mkntfs... Can > > none of the existing library functions (e.g. ntfs_attr_pwrite()) do? > >ntfs_attr_pwrite() does significantly more and actually using/shifting >to its sanity checks would be useful however I suspect it won't work >without some minor modification in its current form. Anyway I'll try >and let you know. Correct. It doesn't support resizing of attributes yet so it would be no use. What you would need is ntfs_attr_truncate() as well as ntfs_attr_pwrite(), but fully implemented so it can extend attributes as POSIX requires. Ok, I will give you ntfs_rlwrite but I will call it ntfs_rl_pwrite() so it will basically have all the functionality you need and more. I will only remove the inited_size parameter and since you don't use it, that is ok. I will put it into disk_io.[ch] as it is too low level to go into attrib.[ch] IMHO. So I will use int fs rather than the ntfs volume to be consistent with the other disk_io functions. > > (This is the one my eyes object to the most.) Also is it ok to > > have ntfs_volume *vol instead of int fd? (Note sure about that, > > may leave it to int fd...). > >IMHO ntfs_volume *vol would be better: version of NTFS and many others >wouldn't be "lost" and some might be useful in the future. That is true however the writing happens at a run list only level without any knowledge of which mft record, etc is being written so knowing which ntfs version it is, is not going to make any difference. This function is useful, I agree, but it is a very low level function. For example if the run list is partially unmapped or if it contain holes the function cannot do anything about it and must just return error. So the uses of this function are quite limited. I think once we have ntfs_attr_pwrite() fully implemented and ntfs_attr_truncate() there will no longer be a need for ntfs_rl_pwrite() at all and if we find that we can always remove it from the library again... Anton -- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ |
