linux-ntfs-dev — Development discussions and bug reports.

[Linux-NTFS-Dev] 8826 endereços emails de Santo Amaro SP

[<mai...@uo...>]

Pacote com 8826 emails da região de Santo Amaro - zona sul de São Paulo

valor R$ 30,00

segmentação & mailing list
www.postdata.com.br

[Linux-NTFS-Dev] attribute list handling

[Anton A. <ai...@ca...>]

(Jeff, this is a copy from irc session in case you didn't get to read it 
and I have added a few more comments, too. I have cc:-ed linux-ntfs-dev, too)

About attribute list reading. The current ntfs tng cvs already reads in the 
attribute list of each inode (assuming the attribute list is non-resident 
otherwise there is no need) and stores both the run list and the attr list 
value itself in vmalloced memory inside the ntfs specific parts of the inode.

And there are two bits in the "state" field of the ntfs specific inode to 
indicate that an attribute list is present and that it is non-resident.

The next step is to complete attribute lookup function and attribute lookup 
external function.

I have them reverse engineered but they need rewriting for us and porting 
to the kernel/current code base.

You can have a look at the reverse engineered stuff in cvs: 
linux-ntfs/libntfs/attrib_RE.c

Basically the ideas behind those are that we stop using find_attr in the code.

We always use lookup_attr instead. (Except in special cases where we are 
going to actually fiddle with the attributes by hand, i.e. in low level code)

lookup_attr then does the right thing by noticing whether an attribute list 
is present or not and doing the correct call into find_attr or 
lookup_external_attr to find the attribute.

Once it finds it, it returns the attribute in an extended search context.

The search context has to include the current state of the search and any 
mft records that were mapped in the process.

We then need a cleanup search context function which will unmap everything 
in the search context.

I am even thinking of having a slab cache for search contexts for efficient 
allocation/deallocation.

The context is necessary so you can find the first part of an attribute and 
then immediately find the next one.

For example when $DATA is split into several attribute extents, you need 
this functionality.

The advantage of doing it this way is that attribute lists are 100% 
transparent to callers of lookup_attr().

It always returns the actual attribute and the caller has not to care 
whether the attribute came from the mft record they submitted in the search 
context or whether it came from an extension mft record referenced by the 
attribute list.

---end of irc session---

In fact you will see the reverse engineered function (lookup_attr) actually 
will happily read in the mft record first so we can do the same. This means 
the caller doesn't even need to call map_mft_record_for_read, they just 
call lookup attr with the struct inode * which they want to search and the 
mapping is done completely transparent and the state is again stored in the 
search context. That makes for quite an extensive search context but 
considering how easy it makes the life of the caller it is well worth it IMO.

What do you think?

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] ntfs_sb_info problem

[Anton A. <ai...@ca...>]

At 23:42 21/11/01, Jeff Garzik wrote:
>On Wed, 21 Nov 2001, Anton Altaparmakov wrote:
> > I have eliminated ntfs out of the include/linux directory completely. The
> > new NTFS TNG CVS doesn't have any files at all outside fs/ntfs/.
> > Accordingly include/linux/fs.h no longer should mention ntfs nor include
> > any ntfs files. NTFS TNG now uses the generic_{i,sb}p pointers to 
> attach fs
> > specific inode/super block data.
>
>w00t!

?!?

> > Jeff, the core kernel patch in ntfs-driver-tng/patches is now updated to
> > edit include/linux/fs.h to remove ntfs out of there. If you want to apply
> > manually just delete the four lines in fs.h containing the string "ntfs"...
>
>will do when I return from holiday...

Cool. Have a good holiday! (-:

Cheers,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] ntfs_sb_info problem

[Jeff G. <jg...@ma...>]

On Wed, 21 Nov 2001, Anton Altaparmakov wrote:
> I have eliminated ntfs out of the include/linux directory completely. The 
> new NTFS TNG CVS doesn't have any files at all outside fs/ntfs/. 
> Accordingly include/linux/fs.h no longer should mention ntfs nor include 
> any ntfs files. NTFS TNG now uses the generic_{i,sb}p pointers to attach fs 
> specific inode/super block data.

w00t!

> So when Jeff merges the current NTFS TNG cvs into his, everyone can compile 
> their kernel with older gcc as long as they don't enable NTFS. If you 
> enabled NTFS you need gcc-2.96.

Well since I was under the impression you needed something more recent
than egcs-1.1.2 anyway, it's all good :)

> Jeff, the core kernel patch in ntfs-driver-tng/patches is now updated to 
> edit include/linux/fs.h to remove ntfs out of there. If you want to apply 
> manually just delete the four lines in fs.h containing the string "ntfs"...

will do when I return from holiday...

	Jeff

Re: [Linux-NTFS-Dev] ntfs_sb_info problem

[Anton A. <ai...@ca...>]

Hi Andrew, Hi Jeff,

I have eliminated ntfs out of the include/linux directory completely. The 
new NTFS TNG CVS doesn't have any files at all outside fs/ntfs/. 
Accordingly include/linux/fs.h no longer should mention ntfs nor include 
any ntfs files. NTFS TNG now uses the generic_{i,sb}p pointers to attach fs 
specific inode/super block data.

So when Jeff merges the current NTFS TNG cvs into his, everyone can compile 
their kernel with older gcc as long as they don't enable NTFS. If you 
enabled NTFS you need gcc-2.96.

That will have to do for now.

Jeff, the core kernel patch in ntfs-driver-tng/patches is now updated to 
edit include/linux/fs.h to remove ntfs out of there. If you want to apply 
manually just delete the four lines in fs.h containing the string "ntfs"...

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Re: ntfs_sb_info problem

[Anton A. <ai...@ca...>]

At 09:20 21/11/01, Andrew Morton wrote:
>Jeff Garzik wrote:
> >
> > On Wed, 21 Nov 2001, Andrew Morton wrote:
> >
> > > Hi, Anton.
> > >
> > > I just pulled a new version of include/linux/ntfs_fs_sb.h
> > > out of Jeff's CVS tree.
> > >
> > > With egcs-1.1.2 I get twelve trillion instances of:
> >
> > Is that a supported 2.4.x compiler?  :)

Sadly it is. I was hoping by the time NTFS TNG would be ready for the 
kernel the minimal gcc requirements would be higher...

The minimum NTFS TNG requirement is gcc-2.96. - I know it doesn't exist 
according to gcc developers but it seems to do a very good job of compiling 
my kernels despite this... (-;

>         grep egcs /usr/src/linux/README
>
>And if anyone takes that away, I'll come after them with
>an elephant gun.  egcs-1.1.2 compiles stuff at twice the
>speed of later versions.

I have to say I absolutely love the unnamed structs/unions. They are 
extremely useful and increase the code clarity no end (without them I have 
to write something like attr->union.resident.value_length and with them 
this simplifies to attr->value_length, the compiler figures out the rest). 
And also, unnamed structs/union have been a longstanding standard feature 
of other OS' compilers... So I can't wait for someone to make the minimum 
compiler requirements gcc-2.96...

/me puts on a kevlar vest and hides behind a big rock.

I suppose once the code is ready for the kernel, I will have to go through 
all of it naming the unions and structs so that it will support old gcc 
versions or Linus probably won't accept it...

Having said that a while ago I saw a trick of how to emulate unnamed 
structs/unions on older gcc compilers. I have to find it somewhere among my 
emails and try to apply it to NTFS TNG. It makes for VERY ugly header files 
but I am hoping I can just have something like layout_compat.h contain all 
the ugly stuff for layout.h, etc. And even better if I can check the gcc 
version and include the _compat.h files conditionally it would be ideal.

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Re: ntfs_sb_info problem

[Andrew M. <ak...@zi...>]

Jeff Garzik wrote:
> 
> On Wed, 21 Nov 2001, Andrew Morton wrote:
> 
> > Hi, Anton.
> >
> > I just pulled a new version of include/linux/ntfs_fs_sb.h
> > out of Jeff's CVS tree.
> >
> > With egcs-1.1.2 I get twelve trillion instances of:
> 
> Is that a supported 2.4.x compiler?  :)

	grep egcs /usr/src/linux/README


And if anyone takes that away, I'll come after them with
an elephant gun.  egcs-1.1.2 compiles stuff at twice the
speed of later versions.

[Linux-NTFS-Dev] Re: ntfs_sb_info problem

[Jeff G. <jg...@ma...>]

On Wed, 21 Nov 2001, Andrew Morton wrote:

> Hi, Anton.
> 
> I just pulled a new version of include/linux/ntfs_fs_sb.h
> out of Jeff's CVS tree.
> 
> With egcs-1.1.2 I get twelve trillion instances of:

Is that a supported 2.4.x compiler?  :)

[Linux-NTFS-Dev] ntfs_sb_info problem

[Andrew M. <ak...@zi...>]

Hi, Anton.

I just pulled a new version of include/linux/ntfs_fs_sb.h
out of Jeff's CVS tree.

With egcs-1.1.2 I get twelve trillion instances of:

/usr/src/gkernel/include/linux/ntfs_fs_sb.h:47: warning: unnamed struct/union that defines no instances
/usr/src/gkernel/include/linux/ntfs_fs_sb.h:62: warning: unnamed struct/union that defines no instances

Similar problem in include/linux/ntfs_fs_i.h

You're going to have to drop the anon structs and unions.

[Linux-NTFS-Dev] NTFS driver TNG (Was: Re: chapter12 -file systems - NTFS recovery support.)

[Anton A. <ai...@ca...>]

Hi everyone,

This list has been quite dormant so I am forwarding this email which 
discusses NTFS TNG driver a bit in the hope to stimulate some discussion on 
this list. (-:

At 20:06 11/11/2001, Jeff Garzik <jg...@ma...> wrote:
>At the moment I'm looking at ntfs-TNG...   You should check out zisofs
>in 2.4.15-pre2...  zisofs_readpage handles the case where compression
>causes you to read in more pages than just the one requested.  It
>injects the other pages into the page cache along with the one
>requested.
>
>Just something to think about :)

Yes, I know. Al Viro and HPA pointed that out to already on linux-fsdevel 
when I asked which fs exist that support transparent compression and use 
the page cache.

I don't have problems injecting pages. I do that already if you look in TNG 
mft.c::map_mft_record_for_read(). I do that there from the ground up so to 
speak (I allocate the page and do all the magic myself rather than calling 
grab_cache_page_no_wait()). I guess the zisofs approach is cleaner because 
it is less complex, might simplify my function some day. For the moment it 
works so no point in wasting time in making it look nicer.

>Also, two questions:

I am assuming we are talking TNG driver in all the below...

>1) for the paranoid, is it ok to perform fixup-on-write (create an
>update sequence) always?  ie. enable fixups for all inodes on write, if
>they do not already use fixups.  I was thinking of that as an option,
>defaulting to off.

It's impossible they don't use fixups. By definition all inodes (MFT 
records) and all INDEX_BLOCKS ($INDEX_ALLOCATION attribute data in other 
words), MUST be protected by fixups.

If you look in the above mentioned map_mft_record_for_read() you will see 
that it reads in all mft records belonging to a page and it uses its own 
end_async_io() handler, which in turn removes the fixups via 
post_read_mst_fixup() before unlocking the page.

Thus anyone calling map_mft_record_for_read() is guaranteed to see data 
clean from fixups.

In the commit to disk path, a dirty page will be locked, marked not 
uptodate and all mft records/inodes will have their mrec_lock semaphores 
downed for writing (not necessarily in this order obviously, the order has 
to fit in with the one map_mft_record_for_read/write() so it doesn't 
deadlock...), then the fixups will be applied via pre_write_mst_fixup(), 
the page written synchronously, the fast __post_read_fixup() function will 
remove the fixups we just applied again, the page will be marked uptodate 
and unlocked and the commit to disk is done.

The only downside to this I can see is that we always flush to disk all mft 
records in a dirty page even if only one of them is dirty. I suppose this 
could be handled more nicely if we have a dirty bit in each mft 
record/inode as well, so we only take the mrec_lock semaphore for writing 
if the record is marked dirty in the first place. But not taking could lead 
to races because we would have to mark the page notuptodate and lock it so 
having unlocked mft records in that might kill us somewhere (maybe, haven't 
thought about it enough yet).

I have pretty much only been focused on getting reading to work. To finish 
it off we need: 1) attribute list support and 2) support for compressed 
files. I  have been thinking for quite a while of how best to implement 
both of these... The reverse engineered functions for attribute list 
searches are plain scary (I know I reverse engineered them but I still 
don't understand the significance of some of the variables in them). You 
can look at the raw reverse engineering results in 
linux-ntfs/include/attrib_RE.h and linux-ntfs/libntfs/attrib_RE.c if you like.

I would very much like to have a stateful search context that can support 
attribute list searches. Just like the reversed functions do but it's not 
straightforward. The current TNG code has just what I would like it to have 
in the find_attr() and find_first_attr() functions in 
tng/linux/fs/ntfs/attrib.c. They employ a nice and easy search context and 
allow (re)commencing searches from any point. The find_attr() function is a 
slightly simplified and optimized result from reverse engineering the 
windows NT4 counterpart. If you have a look you will notice how complex the 
collation of attributes actually is (all the comparison functions called 
are found in unistr.c, again mostly reverse engineered stuff, especially 
the comparison "magic" table and functions accessing it).

>2) have you seen any code or routines for dealing with the B+tree
>directories?  Reading is pretty easy but I want to make sure updating
>directories is optimal.

You mean not counting the lookup() function in TNG? Then I only know of the 
windows NTFS driver itself.

The HPFS driver should be using them as well, since NTFS was designed on 
the basis of it initially but I haven't had a close look.

I started reverse engineering the windows ones and you can see the 
tng/linux/fs/ntfs/dir.c::ntfs_lookup_ino_by_name() is the result but I have 
modified the logic heavily as I never finished the reverse engineering. The 
functions are herrendously complex and a lot of SoftIce use will be 
required to finish them off. The call different collation functions using 
function pointer tables, so they look at some values and then call 
do_some_special_comparison[magic_index]. I haven't figured out how to 
determine which function is used when yet, at least not from just reading 
the code.

My lookup functions seems to be doing a good job though so it might be good 
enough, only time will tell, once we start writing things...

For writing, my idea is to do a directory index lookup() and get returned 
either the found value or the location of where to insert it (function will 
be mostly identical to what 
tng/linux/fs/ntfs/dir.c::ntfs_lookup_ino_by_name() does). Once that is 
done, call an index insertion function, which in turn will do the hard work 
of creating space in the right position, and if that is not possible it 
will make a decision what to do depending on the circumstances or how we 
want to implement it... It could either add the entry in a new index block 
and just link the next entry to this index block or it could split the 
index block in two equal(for some value of equal) parts and then add itself 
to the appropriate part or (fill in with your own ideas)...

As far as I see this, there is no right or wrong way. It's just a B+ tree 
and as long as the order of entries is correct we will work just fine with 
Windows NTFS driver. Once we have it all working we can always switch to 
more sophisticated algorithms for dealing with the trees. Maybe we could 
balance a tree when we detect it is all over the place for example but that 
is all not required. We could always reverse engineer Windows some more if 
we want to do the same thing but I don't see the need - and it's a lot of 
work for something we don't absolutely have to do...

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] ANN: Linux-NTFS 1.4.0 released

[Anton A. <ai...@ca...>]

This is to announce release of Linux-NTFS user space support tools 1.4.0.

Most important changes:

mkntfs now support creation of NTFS floppies and the root directory on=20
volumes with cluster sizes > 4kiB are now created correctly.

ntfsfix now supports Windows XP (NTFS 3.1) volumes.

Linux-NTFS packages (your choice of source tar.gz or rpm, binary i386.rpm=20
and devel rpm) can be downloaded from the Linux-NTFS home page at:

         http://linux-ntfs.sf.net/

Or if you prefer CVS access, look at the project home page on Sourceforge=20
for details how to access the CVS server:

         http://sourceforge.net/cvs/?group_id=3D13956

ChangeLog:

1.4.0: Major fix in mkntfs, small update to ntfsfix, and other updates.

- Update ntfsfix to support Windows XP NTFS volumes (NTFS 3.1).
- Update layout.h with more information.
- (Re)enable shared libraries.
- Changes to mkntfs:
         - Correct handling of directories on volumes with cluster sizes=20
above 4096 bytes.
         - Lower minimum size of NTFS partitions to 1MiB, scaling down the=
=20
logfile size as necessary.
         - Support a wider range of input parameters. Now should have all=20
valid combinations covered.
         - Update man page.
         - Implement better determination of device size.
         - Various bug fixes.

1.2.2: Small fix in mkntfs and minor updates.
- Small fix in mkntfs for small volumes with non-standard sector sizes,=20
where the default values would result in a sector size smaller than the=20
sector size and mkntfs would refuse to run because of this. The man page=20
was updated accordingly.
- Minor updates/clarifications to include/layout.h.

1.2.1: Added ntfsfix man page and minor cleanup.
- David Mart=EDnez Moreno <dav...@re...> donated a man page for=
=20
ntfsfix as well as spelling mistake fixes all over the place.

1.2.0: Important bug fixes to mkntfs.
- Bug fixes for cluster sizes > 4kb involving corrections to mft mirror=20
size and contents, mft data attribute position and mft bitmap=20
size.     Some of those were nasty so this is a major improvement.

For older changes, see the ChangeLog file in the release or in CVS.

Best regards,

         Anton


--=20
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
--=20
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Building RW ntfs driver

[Richard R. <ri...@fl...>]

Hi Maria,

Sorry for the slow reply.

> I need to create a boot diskette with the ability to
> access an ntfs drive (for reading and writing).

OK, it can be done.  But it's quite a bit of work.
Fortunately there are detailed instructions for everything.

One problem,, though, is that using the NTFS driver
to write is dangerous.  The driver isn't finished.
The later the kernel, the less dangerous it will be.

Anyway, first you need to build a kernel.  This isn't
as hard, or scary, as it sounds.  Both RedHat and Mandrake
have the kernel source on their CDs and also the .config
that was used to create their kernel.  Have a look through
the Kernel HOWTO and everything will be explained:

  http://linuxdoc.org/HOWTO/Kernel-HOWTO.html

Once you've got a kernel, you need to build a boot disk.
There are several prebuilt sets of boot and root disks
that might be a good starting point.  Instructions can be
found at:

  http://linuxdoc.org/HOWTO/Bootdisk-HOWTO/index.html

As I said, writing to NTFS, under Linux, isn't very safe.
After you've done so, we recommend you run NTFSFix.  It's
a small utility to check the filesystem and try and let
chkdsk know that we've been meddling.  NTFSFix is in our
NTFS Tools package, on our home page:

  http://sourceforge.net/project/showfiles.php?group_id=13956

Now I've gone through all the difficult methods of writing,
here's an easier one.  SysInternals have a toy called NTFSDos.
It allows you to read from NTFS.  It uses Windows' own system
DLLs.  If you pay for the Pro version it even writes.
But beware, it isn't perfect.  A writing version I tested once
(perhaps it's better now) left errors on the volume.

  http://sysinternals.com/ntw2k/freeware/ntfsdospro.shtml

If you have any other questions, let me know.

Cheers,
  FlatCap (Rich)
  nt...@fl...

[Linux-NTFS-Dev] Building RW ntfs driver

[Maria S. <qe...@ya...>]

I need to create a boot diskette with the ability to
access an ntfs drive (for reading and writing).  I
have access to a Mandrake or RedHat system -- but I am
a windows developer -- It appears that the driver on
the Mandrake system is read-only -- 

can you point me to information on how to build or
rebuild the driver and/or kernel with ntfs write
capability.  

MCS


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

[Linux-NTFS-Dev] LDM [patch] 2.4.12 compatible

[Jakob K. <ja...@te...>]

Hi!

Here's a patch to make the cvs sources for ldm compatible with the most recent
2.4.x kernel sources.

The only files necessary to modify in 2.4.12 is ldm.c and ldm.h (no need for 
special check.c and check.h)

/ Jakob

[Linux-NTFS-Dev] compilation NTFS module (2.4.9)

[Maxim V. K. <kr...@mg...>]

Hi!
At a configuration of a kernel 2.4.9 is ordered as the module support
fs NTFS (without write). At compilation of modules ("make modules")
I receive the following error messages:

--------: < --------
make -C ntfs modules
make [2]: entrance in the cat " /usr/src/linux/fs/ntfs'
gcc -D __ KERNEL __ -I/usr/src/linux/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DNTFS_VERSION =
\ " 1.1.16 \ " -c -o unistr.o unistr.c
unistr.c: In function " ntfs_collate_names':
unistr.c:99: warning: implicit declaration of function "min"
unistr.c:99: parse error before "unsigned"
unistr.c:99: parse error before ")"
unistr.c:97: warning: "c1" might be used uninitialized in this function
unistr.c: At top level:
unistr.c:118: parse error before "if"
unistr.c:123: warning: type defaults to "int" in declaration of "c1"
unistr.c:123: "name1" undeclared here (not in a function)
unistr.c:123: warning: data definition has no type or storage class
unistr.c:124: parse error before "if"
make [2]: *** [unistr.o] Error 1
make [2]: exit from the catalogue " /usr/src/linux/fs/ntfs'
make [1]: *** [_modsubdir_ntfs] a Error 2
make [1]: exit from the catalogue " /usr/src/linux/fs'
make: *** [_mod_fs] a Error 2
 --------------- 

In case of absence of the order on support NTFS all passes without the
errors.

System - PC with chipset i815, Celeron 730, RH 7.1, krnl 2.4.3-12,
gcc 2.96-85 from RH, modutils & kernel 2.4.9 from .org.

How to remove a mistake at compilation of the module of support NTFS?

I shall be grateful for any efficient advice.

Thanx.
-- 
MKV from MyHome // ICQ - 115349623 // AOl - MaximVadim //
pr...@uk...

Re: [Linux-NTFS-Dev] fs/ntfs/unistr.c doesn't compile

[Anton A. <ai...@cu...>]

On Fri, 28 Sep 2001, Hadmut Danisch wrote:
> fs/ntfs/unistr.c doesn't compile with latest
> kernels (2.4.9, 2.4.10, maybe earlier).
> 
> There's a 
> 
> #include <linux/kernel.h>

Correct but problem only exists with 2.4.9. All kernels before 2.4.9 and
all kernels after that are fine.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] fs/ntfs/unistr.c doesn't compile

[Hadmut D. <ha...@da...>]

Hi,

fs/ntfs/unistr.c doesn't compile with latest
kernels (2.4.9, 2.4.10, maybe earlier).

There's a 

#include <linux/kernel.h>


missing.

regards
Hadmut

Re: [Linux-NTFS-Dev] Bug report -- Linux-NTFS

[Richard R. <nt...@fl...>]

Hi SachinB,

> I make NTFS support on in kernel compilation I got following error in
> compiling kernel ...

Yes, it's a known problem.  There are now two solutions, either download
the latest kernel 2.4.10, or add the following line to unistr.c

  #include <linux/kernel.h>

Cheers,
  FlatCap (Rich)
  nt...@fl...

[Linux-NTFS-Dev] Bug report -- Linux-NTFS

[Sachin N B. <sac...@cd...>]

Hello Sir/Madam,

I make NTFS support on in kernel compilation I got following error in
compiling kernel

make bzImage

Error :

gcc -D__KERNEL__ -I/home/sachinb/Kernel2.4.9/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686  -DNTFS_VERSION=\"1.1.16\"   -c -o unistr.o unistr.c
unistr.c: In function `ntfs_collate_names':
unistr.c:99: warning: implicit declaration of function `min'
unistr.c:99: parse error before `unsigned'
unistr.c:99: parse error before `)'
unistr.c:97: warning: `c1' might be used uninitialized in this function
unistr.c: At top level:
unistr.c:118: parse error before `if'
unistr.c:123: warning: type defaults to `int' in declaration of `c1'
unistr.c:123: `name1' undeclared here (not in a function)
unistr.c:123: warning: data definition has no type or storage class
unistr.c:124: parse error before `if'
make[3]: *** [unistr.o] Error 1
make[3]: Leaving directory `/home/sachinb/Kernel2.4.9/fs/ntfs'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/home/sachinb/Kernel2.4.9/fs/ntfs'
make[1]: *** [_subdir_ntfs] Error 2
make[1]: Leaving directory `/home/sachinb/Kernel2.4.9/fs'
make: *** [_dir_fs] Error 2

Bye
Thank you
SachinB 
*******************************************************************************
Sachin N. Bhandare
Applications Group
C-DAC/NPSF, University of Pune,
Gaheshkhind, Pune 411 007.
PH: 91-20-5677402

*******************************************************************************

Re: [Linux-NTFS-Dev] LDM partition order swapping

[Richard R. <ri...@fl...>]

Hi Jakob,

> I've recently been playing around with ldm and dualboot. I've noticed that
> when I for example add a partition in win2k's disk manager the ordering
> changes in Linux. This messes up my raid devices bigtime in Linux

At the moment the driver just creates partitions in the order that it
finds part objects in the database.

> I was wondering if there's any known solutions to the problem.

No.  I'm still waiting for inspiration.

I'm not sure what criterion to sort on.  The partitions are named, but
not in a useful way and sorting by offset won't help either.  The VBLKs
are put into the database in the first available slot.  After a lot of
rearranging, this might as well be random.

How much information do you need to fix your RAID mount?  Would the
following be enough?

  /proc/.../ldm/volumes
      Volume1 Disk1-03
      Volume1 Disk2-04
      ...

  /proc/.../ldm/partitions
      Disk1-03 hda3
      Disk2-04 hda5
      ...

> If there isn't I might get the time to do some research on a fix to this.

I'm happy to listen to any suggestions, happier still for code :-)

I've just re-written the code to understand extended VBLKs now.  And I'm just
about to update the docs, too.  If you're patient, I'll release 0.0.5 in the
next couple of days.  If not you can fetch the source from the CVS repository:

  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linux-ntfs co dynamic-disk

(This should all be one line)

Cheers,
  FlatCap (Rich)
  nt...@fl...

[Linux-NTFS-Dev] LDM partition order swapping

[Jakob K. <jak...@te...>]

Hi!

I've recently been playing around with ldm and dualboot. I've noticed that
when I for example add a partition in win2k's disk manager the ordering
changes in Linux. This messes up my raid devices bigtime in Linux and I was
wondering if there's any known solutions to the problem. If there isn't I
might get the time to do some research on a fix to this.
Please CC me since I'm not on the list!

/ Jakob

Re: [Linux-NTFS-Dev] Fw: error while compiling kernel with ntfs-support

[Anton A. <ai...@ca...>]

Known problem, correct solution. Is fixed long ago (since 2.4.10-pre1).

Anton

At 12:14 13/09/01, Kevin D. Kissell wrote:
>OK, I guess I should have copied this list when I first posted
>the following to linux.dev.kernel...
>
>----- Original Message -----
>From: "Kevin D. Kissell" <ke...@pa...>
>Newsgroups: linux.dev.kernel
>Sent: Thursday, September 13, 2001 10:24 AM
>Subject: Re: error while compiling kernel with ntfs-support
>
>
> > I downloaded 2.4.9 this morning and found exactly the same problem.
> > Only one line is changed between the 2.4.7 and 2.4.9 versions of that
> > file, and the change is to use a newly defined three-operand min() macro
> > instead of a traditional 2-operand min().  The problem is that the
> > definition
> > of the macro is in include/linux/kernel.h, which is not included by
> > fs/ntfs/unistr.c, nor by any of its include files.  I experimentally
>applied
> > the following patch, and the rest of the kernel built and installed
>cleanly,
> > and seems to run.
> >
> > ------------ Begin Patch ----------
> > --- unistr.c.2.4.9 Thu Sep 13 09:51:28 2001
> > +++ unistr.c Thu Sep 13 09:53:17 2001
> > @@ -23,6 +23,7 @@
> >
> >  #include <linux/string.h>
> >  #include <asm/byteorder.h>
> > +#include <linux/kernel.h>
> >
> >  #include "unistr.h"
> >  #include "macros.h"
> >
> > -------- End Patch -------------
> >
> > However, the NTFS maintainer may instead want to have
> > kernel.h picked up by some higher level include file, rather
> > than by the C file itself.  Personally, given the multiple instances
> > of a 2-operand min() that still exist within the kernel, I would
> > have recommended using a different name ("min_t" or
> > whatever) for the new 3-operand version, to avoid
> > programmer/compiler/linker confusion.
> >
> >             Kevin K.
> >
> > "Erika Tiefengraber" <eri...@ao...> wrote in message
> > news:3b9f8460$0$43430$6e3...@ne......
> > > Erika Tiefengraber wrote:
> > >
> > > > Ich tried to compile kernel 2.4.9 with support for
> > > > NTFS
> > > > First i tried to compile it as a Module
> > > > Then i tried to compile it into the kernel
> > > >
> > > > on both experiments, i got a compiler error
> > > > but it was OK without NTFS support
> > > > is there a known problem
> > > The error message is
> > >
> > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> > > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
> > > -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS
> > > -include /usr/src/linux/include/linux/modversions.h
> > > -DNTFS_VERSION=\"1.1.16\"   -c -o unistr.o unistr.c
> > > unistr.c: In function `ntfs_collate_names':
> > > unistr.c:99: warning: implicit declaration of function `min'
> > > unistr.c:99: parse error before `unsigned'
> > > unistr.c:99: parse error before `)'
> > > unistr.c:97: warning: `c1' might be used uninitialized in this function
> > > unistr.c: At top level:
> > > unistr.c:118: parse error before `if'
> > > unistr.c:123: warning: type defaults to `int' in declaration of `c1'
> > > unistr.c:123: `name1' undeclared here (not in a function)
> > > unistr.c:123: warning: data definition has no type or storage class
> > > unistr.c:124: parse error before `if'
> > > make[2]: *** [unistr.o] Error 1
> > > make[2]: Leaving directory `/usr/src/linux/fs/ntfs'
> > > make[1]: *** [_modsubdir_ntfs] Error 2
> > > make[1]: Leaving directory `/usr/src/linux/fs'
> > > make: *** [_mod_fs] Error 2
> > >
> > >
> > > this error is independent of hardware
> > > We tried to compile on
> > > different Computers
> >
> >
>
>
>_______________________________________________
>Linux-NTFS-Dev mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev

-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Fw: error while compiling kernel with ntfs-support

[Kevin D. K. <ke...@pa...>]

OK, I guess I should have copied this list when I first posted
the following to linux.dev.kernel...

----- Original Message -----
From: "Kevin D. Kissell" <ke...@pa...>
Newsgroups: linux.dev.kernel
Sent: Thursday, September 13, 2001 10:24 AM
Subject: Re: error while compiling kernel with ntfs-support


> I downloaded 2.4.9 this morning and found exactly the same problem.
> Only one line is changed between the 2.4.7 and 2.4.9 versions of that
> file, and the change is to use a newly defined three-operand min() macro
> instead of a traditional 2-operand min().  The problem is that the
> definition
> of the macro is in include/linux/kernel.h, which is not included by
> fs/ntfs/unistr.c, nor by any of its include files.  I experimentally
applied
> the following patch, and the rest of the kernel built and installed
cleanly,
> and seems to run.
>
> ------------ Begin Patch ----------
> --- unistr.c.2.4.9 Thu Sep 13 09:51:28 2001
> +++ unistr.c Thu Sep 13 09:53:17 2001
> @@ -23,6 +23,7 @@
>
>  #include <linux/string.h>
>  #include <asm/byteorder.h>
> +#include <linux/kernel.h>
>
>  #include "unistr.h"
>  #include "macros.h"
>
> -------- End Patch -------------
>
> However, the NTFS maintainer may instead want to have
> kernel.h picked up by some higher level include file, rather
> than by the C file itself.  Personally, given the multiple instances
> of a 2-operand min() that still exist within the kernel, I would
> have recommended using a different name ("min_t" or
> whatever) for the new 3-operand version, to avoid
> programmer/compiler/linker confusion.
>
>             Kevin K.
>
> "Erika Tiefengraber" <eri...@ao...> wrote in message
> news:3b9f8460$0$43430$6e3...@ne......
> > Erika Tiefengraber wrote:
> >
> > > Ich tried to compile kernel 2.4.9 with support for
> > > NTFS
> > > First i tried to compile it as a Module
> > > Then i tried to compile it into the kernel
> > >
> > > on both experiments, i got a compiler error
> > > but it was OK without NTFS support
> > > is there a known problem
> > The error message is
> >
> > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
> > -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
> > -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS
> > -include /usr/src/linux/include/linux/modversions.h
> > -DNTFS_VERSION=\"1.1.16\"   -c -o unistr.o unistr.c
> > unistr.c: In function `ntfs_collate_names':
> > unistr.c:99: warning: implicit declaration of function `min'
> > unistr.c:99: parse error before `unsigned'
> > unistr.c:99: parse error before `)'
> > unistr.c:97: warning: `c1' might be used uninitialized in this function
> > unistr.c: At top level:
> > unistr.c:118: parse error before `if'
> > unistr.c:123: warning: type defaults to `int' in declaration of `c1'
> > unistr.c:123: `name1' undeclared here (not in a function)
> > unistr.c:123: warning: data definition has no type or storage class
> > unistr.c:124: parse error before `if'
> > make[2]: *** [unistr.o] Error 1
> > make[2]: Leaving directory `/usr/src/linux/fs/ntfs'
> > make[1]: *** [_modsubdir_ntfs] Error 2
> > make[1]: Leaving directory `/usr/src/linux/fs'
> > make: *** [_mod_fs] Error 2
> >
> >
> > this error is independent of hardware
> > We tried to compile on
> > different Computers
>
>

Re: [Linux-NTFS-Dev] Linux 2.4.9 Kernel - Won't Compile with NTFS Read Enabled!

[Anton A. <ai...@ca...>]

Just add

#include <linux/kernel.h>

to fs/ntfs/unistr.c and all is fine.

Anton


At 07:40 10/09/2001, Caniffe wrote:


>make[3]: Entering directory `/usr/src/linux-2.4.9/fs/ntfs'
>gcc -D__KERNEL__ -I/usr/src/linux-2.4.9/include -Wall -Wstrict-prototypes -W
>no-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
>  -mpreferred-stack-boundary=2 -march=i686  -DNTFS_VERSION=\"1.1.16\"   -c -o
>sysctl.o sysctl.c
>gcc -D__KERNEL__ -I/usr/src/linux-2.4.9/include -Wall -Wstrict-prototypes -W
>no-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
>  -mpreferred-stack-boundary=2 -march=i686  -DNTFS_VERSION=\"1.1.16\"   -c -o
>unistr.o unistr.c
>unistr.c: In function `ntfs_collate_names':
>unistr.c:99: warning: implicit declaration of function `min'
>unistr.c:99: parse error before `unsigned'
>unistr.c:99: parse error before `)'
>unistr.c:97: warning: `c1' might be used uninitialized in this function
>unistr.c: At top level:
>unistr.c:118: parse error before `if'
>unistr.c:123: warning: type defaults to `int' in declaration of `c1'
>unistr.c:123: `name1' undeclared here (not in a function)
>unistr.c:123: warning: data definition has no type or storage class
>unistr.c:124: parse error before `if'
>
>
>Stock 2.4.9 kernel source, just freshly squeezed.  No luck.
>
>--
>Julian "Caniffe" Buckley
>http://www.caniffe.org
>
>
>_______________________________________________
>Linux-NTFS-Dev mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev

-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Linux 2.4.9 Kernel - Won't Compile with NTFS Read Enabled!

[Caniffe <ca...@ca...>]

make[3]: Entering directory `/usr/src/linux-2.4.9/fs/ntfs'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.9/include -Wall -Wstrict-prototypes -W
no-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
 -mpreferred-stack-boundary=2 -march=i686  -DNTFS_VERSION=\"1.1.16\"   -c -o
sysctl.o sysctl.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.9/include -Wall -Wstrict-prototypes -W
no-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe
 -mpreferred-stack-boundary=2 -march=i686  -DNTFS_VERSION=\"1.1.16\"   -c -o
unistr.o unistr.c
unistr.c: In function `ntfs_collate_names':
unistr.c:99: warning: implicit declaration of function `min'
unistr.c:99: parse error before `unsigned'
unistr.c:99: parse error before `)'
unistr.c:97: warning: `c1' might be used uninitialized in this function
unistr.c: At top level:
unistr.c:118: parse error before `if'
unistr.c:123: warning: type defaults to `int' in declaration of `c1'
unistr.c:123: `name1' undeclared here (not in a function)
unistr.c:123: warning: data definition has no type or storage class
unistr.c:124: parse error before `if'


Stock 2.4.9 kernel source, just freshly squeezed.  No luck.

--
Julian "Caniffe" Buckley
http://www.caniffe.org