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

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

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

Hi Joe,

> You actually need to put the pragma inline,

True, but I don't think this is a problem for us.  We want most of our
structures packed, but it doesn't matter if the other ones are too.
This means we can either put a #prama in compat.h or simply compile with
an equivalent option: /Zp1

> This is one of the reasons Stallman uses to
> justify use of __attribute__ rather than pragma.

Hmm, interesting.

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

[Linux-NTFS-Dev] ANN: Snapshot of current ntfsprogs BK repository files

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

Due to request, I have made available a snapshot of the ntfsprogs
BK repository as of a few minutes ago (formerly linux-ntfs CVS and later
linux-ntfs BK repositories). I don't expect any major changes to happen
between the code in this snapshot and the next major release (2.0.0) which
should be happening in the very near future.

The snapshot is available at below URL. I will try and put up new
snapshots whenever significant bug fixes or code changes are committed to
the BK repository.

So here is where to find the current and future snapshots:

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

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] New libntfs API

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

Hi all,

I have recently committed all (hopefully all) of the renames necessary to
get a proper stable API for the ntfs library. Please everyone have a look
through the library (header files would be sufficient to give an idea of
what functions are exported) and let me know what you think and if there
is anything that still needs renaming or changing before the final
release.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] [PATCH] 2.5.51 ntfs - GCC3

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

This patch is completely wrong. Please do not apply.

On Tue, 10 Dec 2002, Justin Pryzby wrote:
> What was going on with 2.96<=__GNUC__<3 ?!

gcc-2.96 introduces unnamed unions and structures which we make heavy use
of in the NTFS driver. To be able to compile with earlier gcc versions, we
had to do some macro magic which is what the below code snippet in your
patch shows. The idea is that as soon as the official kernel requirements
for the minimum compiler are raised to gcc-2.96 or above, we will remove
all the macro magic and just leave everything unnamed.

Unfortunately the gcc crew fscked up and broke typedefs to unnamed unions
and structures in gcc-3.1 I think it was. This has since been fixed again
in the more recent gcc versions (gcc-3.2 is ok).

So if any special casing needs to be made below it would be to extend the
existing test with an || (__GNUC__ == 3 && __GNUC_MINOR__ == 1) but I
prefer not to do that. People should just upgrade their compiler. After
all it is the compiler that is broken not the code.

Best regards,

	Anton

> 
> Justin
> 
> diff -Naur linux-2.5.51.org/fs/ntfs/types.h linux-2.5.51.ntfs/fs/ntfs/types.h
> --- linux-2.5.51.org/fs/ntfs/types.h	2002-12-10 02:17:52.000000000 -0500
> +++ linux-2.5.51.ntfs/fs/ntfs/types.h	2002-12-10 02:41:31.000000000 -0500
> @@ -23,12 +23,12 @@
>  #ifndef _LINUX_NTFS_TYPES_H
>  #define _LINUX_NTFS_TYPES_H
>  
> -#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 96)
> -#define SN(X)   X	/* Struct Name */
> -#define SC(P,N) P.N	/* ShortCut: Prefix, Name */
> -#else
> +#if __GNUC__ == 2 && __GNUC_MINOR__ >= 96
>  #define SN(X)
>  #define SC(P,N) N
> +#else
> +#define SN(X)   X	/* Struct Name */
> +#define SC(P,N) P.N	/* ShortCut: Prefix, Name */
>  #endif
>  
>  /* 2-byte Unicode character type. */
> 
> 

-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] [PATCH] 2.5.51 ntfs - GCC3

[Justin P. <jus...@us...>]

Trivial patch for GCC3.
What was going on with 2.96<=__GNUC__<3 ?!

Justin

diff -Naur linux-2.5.51.org/fs/ntfs/types.h linux-2.5.51.ntfs/fs/ntfs/types.h
--- linux-2.5.51.org/fs/ntfs/types.h	2002-12-10 02:17:52.000000000 -0500
+++ linux-2.5.51.ntfs/fs/ntfs/types.h	2002-12-10 02:41:31.000000000 -0500
@@ -23,12 +23,12 @@
 #ifndef _LINUX_NTFS_TYPES_H
 #define _LINUX_NTFS_TYPES_H
 
-#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 96)
-#define SN(X)   X	/* Struct Name */
-#define SC(P,N) P.N	/* ShortCut: Prefix, Name */
-#else
+#if __GNUC__ == 2 && __GNUC_MINOR__ >= 96
 #define SN(X)
 #define SC(P,N) N
+#else
+#define SN(X)   X	/* Struct Name */
+#define SC(P,N) P.N	/* ShortCut: Prefix, Name */
 #endif
 
 /* 2-byte Unicode character type. */

Re: [Linux-NTFS-Dev] ntfs write code

[Petter Nordahl-H. <pno...@eu...>]

On Mon, 9 Dec 2002, Szakacsits Szabolcs wrote:

>
> On Mon, 9 Dec 2002, Brad Bailey wrote:
>
> > A boot floppy that can be found through astalavista is
> > a NT password changer and registry editor. It
> > obviously has write back support. I've never had it
> > destroy the filesystem, either. The author claims it's
> > been tested on NT, 2K, 2Ks. I've also ran it on XP,
> > and it worked fine.

Ah, the floppy is my project :)


>
> Some notes,
>
> - NT password changer only makes some minimal changes to some data on
>   NTFS that's much-much easier than a full featured write driver

It always writes back files with the same size, yes. And only a tiny
fraction of them have been changed. And only 1-3 files usually.
There have been a lot of reports of the old NTFS-driver failing,
usually the changes did not take place. Only rarely have people told about
heavy corruption because of my use of it.
But there are of course people not reporting.

> - it uses Anton's code, ntfsfix from ntfsprogs to schedule a
>   chkdsk at Windows boot and reset journal file to lessen the
>   chance of destroying the filesystem

It did, yes.

> - I'm about 100% sure the NTFS driver is the old one that is
>   known to be very dangerous (a.k.a broken). .... Hmm, I just
>   checked and actually the latest release changed to Anton's driver
>   that has write-over support.

Yes, I used the 1.6.0(?) patch for 2.4.20 kernel.
The write-in-place seems to be more correct.
And it also reads much better.
But I'll wait and see for the feedback before I can really tell :)

Thanks to Anton and all other involved with NTFS!

And some off-topic:
My next project after adding support for account lockouts/disable and
other state flags for the account database (mostly done), will hopefully
be full registry write support. I know how, but am just lousy writing
code.
Then it will also support extending the filesize.
And need that too from NTFS-driver.

Someone a few years ago used some of my early code to write a
registry-filesystem for linux, so that a registry hive can be mounted
as a filesystem. I think I've lost that one. Anyone knows who?


My project at:
http://home.eunet.no/~pnordahl/ntpasswd/
(as you can see, html and webdesign is not my trade.. :)
-- 
Petter Nordahl-Hagen, pno...@eu...

Re: [Linux-NTFS-Dev] ntfs write code

[Szakacsits S. <sz...@si...>]

On Mon, 9 Dec 2002, Brad Bailey wrote:

> A boot floppy that can be found through astalavista is
> a NT password changer and registry editor. It
> obviously has write back support. I've never had it
> destroy the filesystem, either. The author claims it's
> been tested on NT, 2K, 2Ks. I've also ran it on XP,
> and it worked fine.

Some notes,

- NT password changer only makes some minimal changes to some data on
  NTFS that's much-much easier than a full featured write driver

- it uses Anton's code, ntfsfix from ntfsprogs to schedule a
  chkdsk at Windows boot and reset journal file to lessen the
  chance of destroying the filesystem

- I'm about 100% sure the NTFS driver is the old one that is
  known to be very dangerous (a.k.a broken). .... Hmm, I just
  checked and actually the latest release changed to Anton's driver
  that has write-over support.

In short, you are very lucky and/or it seems the minimal operations
needed to achieve by chntpw are working with quite good probability
with the old NTFS driver. And the last release uses what's linux-ntfs
team is working on.

	Szaka

[Linux-NTFS-Dev] ntfs write code

[Brad B. <mo_...@ya...>]

I'm not a programmer, but have been folowing the
development of ntfs driver. An Idea I've had for a
while on working write code...

A boot floppy that can be found through astalavista is
a NT password changer and registry editor. It
obviously has write back support. I've never had it
destroy the filesystem, either. The author claims it's
been tested on NT, 2K, 2Ks. I've also ran it on XP,
and it worked fine. 

I remember the NTFS driver for Win9X being brought
up... why not look into an NTFS driver already on a
linux system?

---Brad

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Linux-NTFS-Dev] new linux-ntfs sources?

[Andrew C. <cl...@gn...>]

Hi all,

I'd like to look at (and possibly contribute to, depending on free
time and all...) ntfstools / libntfs.

1.6.0 looks quite different to what I can see on the bkbits.net webpage.

Is there a way I can access newish source without using non-free
software?  If not, can someone upload snapshots occassionally?

Thanks,
Andrew

[Linux-NTFS-Dev] runlist renames

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

Hi all,

as discussed (off list I am afraid), I have just renamed all occurances of
"run list", "run_list", and "run-list" to just "runlist" establishing one
single and simple way of writing it.

The changes are now in the ntfsprogs repository on bkbits.net.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

[Joseph M. <jma...@st...>]

Yep.  You actually need to put the pragma inline, rather than as a macro -
at least when using VC++6.  This is one of the reasons Stallman uses to
justify use of __attribute__ rather than pragma.

-joe

On Sat, 7 Dec 2002, Anton Altaparmakov wrote:

> Hi,
>
> On Sat, 7 Dec 2002, Yuri Per wrote:
> > All this things will not work because MS compiler can change packing
> > options only with #pragma.
>
> Yes I know but why should it not work? Do pragma's get evaluated before
> defines? That would be the only reason I could see for it not working...
>
> Best regards,
>
> 	Anton
> --
> Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
> Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
> WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-NTFS-Dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev
>

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

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

Hi,

On Sat, 7 Dec 2002, Yuri Per wrote:
> All this things will not work because MS compiler can change packing 
> options only with #pragma.

Yes I know but why should it not work? Do pragma's get evaluated before
defines? That would be the only reason I could see for it not working...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

[Yuri P. <yu...@ac...>]

Hello!

All this things will not work because MS compiler can change packing 
options only with #pragma.


Yuri


Richard Russon wrote:

>Hi Anton,
>
>  
>
>>>__PACKED__
>>>typedef enum {
>>>	ABC = 4,
>>>} RICH __attriute__ ((packed__));
>>>__UNPACKED__
>>>      
>>>
>>Having thought about this some more, it is not that bad. But we should
>>take it a bit further to make it cleaner.
>>    
>>
>
>OK, good.
>
>  
>
>>PACKED_TYPEDEF struct {
>>	blah = 4,
>>} mystructname PACKED_TYPEDEF_END;
>>    
>>
>
>I'll have a think.  I don't want to mess up the code unnessarily.
>
>  
>
>>PACKED_TYPEDEF enum {
>>	blah = 4,
>>} myenumname PACKED_TYPEDEF_END;
>>    
>>
>
>The enums will take a bit of thought.  We can't put them directly into
>the structs.
>
>  
>
>>And then have the compat.h header file deal with defining...
>>That makes it even nicer than the __attribute__ strangeness and
>>the pragma strangeness that gcc and msvc have respectively.
>>    
>>
>
>Yeah, that's sounding good.
>
>  
>
>>So basically feel free and do something along those lines if you wish...
>>    
>>
>
>Cheers,
>  FlatCap (Rich)
>  nt...@fl...
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Linux-NTFS-Dev mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev
>  
>

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

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

Hi Anton,

> > __PACKED__
> > typedef enum {
> > 	ABC = 4,
> > } RICH __attriute__ ((packed__));
> > __UNPACKED__
> 
> Having thought about this some more, it is not that bad. But we should
> take it a bit further to make it cleaner.

OK, good.

> PACKED_TYPEDEF struct {
> 	blah = 4,
> } mystructname PACKED_TYPEDEF_END;

I'll have a think.  I don't want to mess up the code unnessarily.

> 
> PACKED_TYPEDEF enum {
> 	blah = 4,
> } myenumname PACKED_TYPEDEF_END;

The enums will take a bit of thought.  We can't put them directly into
the structs.

> And then have the compat.h header file deal with defining...
> That makes it even nicer than the __attribute__ strangeness and
> the pragma strangeness that gcc and msvc have respectively.

Yeah, that's sounding good.

> So basically feel free and do something along those lines if you wish...

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

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

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

On Mon, 2 Dec 2002, Anton Altaparmakov wrote:
> On 2 Dec 2002, Richard Russon wrote:
> > We also seem to be relying on the size of __packed__ enums.  It's a
> > nice feature, but it's another gcc extension.  In our code we can:
> 
> I _don't_ care. I don't want pragmas everywhere! gcc doesn't understand
> pragmas anyway so the only way to be compatible with MSVC would be to do
> some disgusting things like:
> 
> #ifdef MSVC
> #define __PACKED__ <insert correct pragma crap here>
> #define __UNPACKED__ <insert correct pragme crap here>
> #define __attrbiute__ <what do we put here so it disappears?!?>
> #define __packed__ <what do we put here so it disappears?!?>
> #else
> #define __PACKED__ <what do we put here so it disappears?!?>
> #define __UNPACKED__ <what do we put here so it disappears?!?>
> #endif
> 
> And then we rewrite:
> 
> >   typedef enum {
> >     ABC = 4,
> >   } RICH __attribute__ ((__packed__));
> 
> to:
> 
> __PACKED__
> typedef enum {
> 	ABC = 4,
> } RICH __attriute__ ((packed__));
> __UNPACKED__

Having thought about this some more, it is not that bad. But we should
take it a bit further to make it cleaner.

Let's have a PACKED_TYPEDEF define as well as a PACKED_TYPEDEF_END (or
something to that effect, feel free to use a better name...).

So the header files would then become:


PACKED_TYPEDEF enum {
	blah = 4,
} myenumname PACKED_TYPEDEF_END;

or 

PACKED_TYPEDEF struct {
	blah = 4,
} mystructname PACKED_TYPEDEF_END;

And then have the compat.h header file (or whatever the name was) deal
with defining PACKED_TYPEDEF{,_END} depending on compiler/OS or whatever
you like. That makes it even nicer than the __attribute__ strangeness and
the pragma strangeness that gcc and msvc have respectively.

So basically feel free and do something along those lines if you wish...

Cheers,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] [ANN] NTFS 2.1.0a for Linux 2.4.20

[Matthew J. F. <ma...@un...>]

The new NTFS driver 2.1.0 (a) is now available for the 2.4.20 kernel.=20

You can grab it along with ntfstools and other patches from=20
http://linux-ntfs.sf.net


Regards,

Matthew J. Fanto
Linux-NTFS Project
#ntfs - irc.openprojects.net

Re: [Linux-NTFS-Dev] Portability of NTFS userspace code

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

On 2 Dec 2002, Richard Russon wrote:
> I've just committed a few changes to the ntfsprogs.
> 
> I've added compat.[ch] to hide a host of minor tweaks that will be
> needed to get things to compile on Windows.  This is enough to get
> around most of the GCCisms of the code, e.g. __attribute__.
> 
> One thing I've had to change is the reliance on void * arithmetic.
> I was quite alarmed when I realised that gcc allows:

I wasn't alarmed. I liked and used it. (-;

>   void *v = "abc";
>   v++;
> 
> It seems that they've decided to define sizeof (void) == 1.  Sensible,
> but I don't think it's a standard.  At the moment, I've just cast the
> pointers to (u8*).  A warning for this can be turned on using
> -Wpointer-arith

Ok, fair enough, but don't expect me to remember it...

> We also seem to be relying on the size of __packed__ enums.  It's a
> nice feature, but it's another gcc extension.  In our code we can:

I _don't_ care. I don't want pragmas everywhere! gcc doesn't understand
pragmas anyway so the only way to be compatible with MSVC would be to do
some disgusting things like:

#ifdef MSVC
#define __PACKED__ <insert correct pragma crap here>
#define __UNPACKED__ <insert correct pragme crap here>
#define __attrbiute__ <what do we put here so it disappears?!?>
#define __packed__ <what do we put here so it disappears?!?>
#else
#define __PACKED__ <what do we put here so it disappears?!?>
#define __UNPACKED__ <what do we put here so it disappears?!?>
#endif

And then we rewrite:

>   typedef enum {
>     ABC = 4,
>   } RICH __attribute__ ((__packed__));

to:

__PACKED__
typedef enum {
	ABC = 4,
} RICH __attriute__ ((packed__));
__UNPACKED__

I am sorry but that is so disgusting I don't want to see it!

> The size of the type for the enum will be minimised, in this case to
> 1 byte.  Then we can use it in a struct, e.g.:
> 
>   struct x {
>     int a;
>     RICH r;
>     int b;
>   };
> 
> We rely on the enum being just one byte, but that's not portable.

Linux-NTFS only compiles with gcc (and as you know we are even very picky 
about which version of gcc...). That is not by accident, it is by
design...

> One solution is to create and use the enumeration, but create a
> strictly sized type for the struct, e.g.
> 
>   enum rich {
>     ABC = 4,
>   };
>   typedef u8	RICH;
> 
>   struct x {
>     int a;
>     RICH r;
>     int b;
>   };

I don't like that. It makes type checking impossible. The whole point of
enums is to allow type checking.

> The next problem is the casting of parameters for Dprintf.  At the
> moment a lot of variables are cast to long long.  Windows doesn't
> like "long long" and prefers "__int64".  Being two words, I can't
> #define my way out of this.

Interesting one! That is really amusing. Windows can go to hell...

> I remember some reason (in kernel space) for this casting.  Some reason
> why we couldn't use the pre-defined types.  Anton?  Now we're in
> userspace, can we change:
> 
>   Dprintf ("Big number %Lu\n", (unsigned long long) num);
> 
> to:
> 
>   Dprintf ("Big number %Lu\n", (u64) num);

We can't do that because %Lu is by definition unsigned long long and not
u64. There are architectures where %L != 64-bit. This has been pointed out
repeatedly on lkml now (by one of the Dave's, DaveM perhaps? or maybe it
was HPA, not sure, but in either case I would take his word for it).

> If not, can we not simply #define our types instead of typedef'ing them?

Doesn't allow type checking. Which is why I don't like it. Just like for
the enums.

I don't believe in code that compiles on all compilers and all OS. All
commercial code I have seen (ok I may not have seen much but I have seen
some huge codebases which compile on 30+ architectures and pretty much
every OS in existence) always keeps separate code for each OS, and I would
really like to keep it this way considering the amount of header file uck
required for MSVC on Windows. If we keep going like this the MacOS people
will come next and add their own compatibility stuff and then the nice
clean (IMO) header files will turn into non-intelligible gobbledigook.

Sorry about the downbeat email, but I said from the beginning that I
didn't like the idea of compiling under MSVC and I predicted it would lead
to a lot of ugliness. And the above just proves how right I was (I
actually underestimated the amount of ugliness). The two compilers are
just way too different. )-:

Cheers,

	Anton
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Portability of NTFS userspace code

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

Hi all,

I've just committed a few changes to the ntfsprogs.

I've added compat.[ch] to hide a host of minor tweaks that will be
needed to get things to compile on Windows.  This is enough to get
around most of the GCCisms of the code, e.g. __attribute__.

One thing I've had to change is the reliance on void * arithmetic.
I was quite alarmed when I realised that gcc allows:

  void *v = "abc";
  v++;

It seems that they've decided to define sizeof (void) == 1.  Sensible,
but I don't think it's a standard.  At the moment, I've just cast the
pointers to (u8*).  A warning for this can be turned on using
-Wpointer-arith

We also seem to be relying on the size of __packed__ enums.  It's a
nice feature, but it's another gcc extension.  In our code we can:

  typedef enum {
    ABC = 4,
  } RICH __attribute__ ((__packed__));

The size of the type for the enum will be minimised, in this case to
1 byte.  Then we can use it in a struct, e.g.:

  struct x {
    int a;
    RICH r;
    int b;
  };

We rely on the enum being just one byte, but that's not portable.
One solution is to create and use the enumeration, but create a
strictly sized type for the struct, e.g.

  enum rich {
    ABC = 4,
  };
  typedef u8	RICH;

  struct x {
    int a;
    RICH r;
    int b;
  };

The next problem is the casting of parameters for Dprintf.  At the
moment a lot of variables are cast to long long.  Windows doesn't
like "long long" and prefers "__int64".  Being two words, I can't
#define my way out of this.

I remember some reason (in kernel space) for this casting.  Some reason
why we couldn't use the pre-defined types.  Anton?  Now we're in
userspace, can we change:

  Dprintf ("Big number %Lu\n", (unsigned long long) num);

to:

  Dprintf ("Big number %Lu\n", (u64) num);

If not, can we not simply #define our types instead of typedef'ing them?

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

WWW: http://linux-ntfs.sf.net
IRC: #ntfs on irc.freenode.net

[Linux-NTFS-Dev] (±¤°í)¡Ú°³ÀÎÀÌ ¿î¿µÇÏ´Â ±â¾÷Çü Á¾ÇÕ¼îÇθô!!!¼ÒÀÚº» â¾÷/ºÎ¾÷!!!¡Ú

[â¾÷ºÎ¾÷Áö¿ø <ad...@so...>]

<html> 
<head> 
<meta http-equiv="content-type" content="text/html; charset=euc-kr"> 
<title>(광고)★무점포,소자본 창업의 기회를 잡으세요!★</title> 
<meta name="generator" content="Namo WebEditor v5.0"> 
</head> 
<body bgcolor="#e1eff6" text="black" link="blue" vlink="purple" alink="red"> 
<table cellpadding="0" cellspacing="0" width="560" align="center"> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img01.jpg" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img02.jpg" width="560" height="98" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img03.jpg" width="560" height="111" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img04.jpg" width="560" height="121" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img05.jpg" width="560" height="116" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img06.jpg" width="560" height="108" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947"> 
<p><a href="http://www.sohomart4u.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/img07_1.gif" width="560" height="44" border="0"></a></p> 
</td> 
</tr> 
<tr> 
<td width="947" height="108" background="http://www.sohomart4u.com/mail777/images/img08.gif"> 
<table align="center" cellpadding="0" cellspacing="0" width="533"> 
<tr> 
<td width="144"> 
<p>&nbsp;</p> 
</td> 
<td width="133"> 
<p><a href="http://www.sohomart4u.com/page/mailnew/mj.htm" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/b1.jpg" width="137" height="37" border="0"></a></p> 
</td> 
<td width="153"> 
<p><a href="http://www.sohomart4u.com/page/mailnew/ser1_1.htm" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/b2.jpg" width="137" height="37" border="0"></a></p> 
</td> 
<td width="103"> 
<p>&nbsp;</p> 
</td> 
</tr> 
<tr> 
<td width="144"> 
<p>&nbsp;</p> 
</td> 
<td width="133"> 
<p><a href="http://www.sohomart4u.com/page/mailnew/mj3.htm" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/b3.jpg" width="137" height="37" border="0"></a></p> 
</td> 
<td width="153"> 
<p><a href="http://www.sohonuri.com" target="_blank"><img src="http://www.sohomart4u.com/mail777/images/b4.jpg" width="137" height="37" border="0"></a></p> 
</td> 
<td width="103"> 
<p>&nbsp;</p> 
</td> 
</tr> 
</table> 
</td> 
</tr> 
<tr> 
<td width="947" bgcolor="#c4dffa"> 
<p align="center"><b><font size="2">:: &nbsp;연락처 안내 &nbsp;::&nbsp;</font></b></p> 
</td> 
</tr> 
<tr> 
<td width="947" bgcolor="white"> 
<p><br><FONT size=2>주소 : 서울특별시 서초구 서초2동 1337-8 보통빌딩 
405호<br>담당 : 주세훈<br>TEL : 080-224-5500<br>사이트 : <a href="http://www.sohomart4u.com" target="_blank">http://www.sohomart4u.com</a><br>&nbsp;</FONT></p> 
</td> 
</tr> 
<tr> 
<td width="947" bgcolor="#c4dffa"> 
<P align="center"><b><font size="2">:: &nbsp;광고안내 &nbsp;::</font></b></P> 
</td> 
</tr> 
<tr> 
<td width="947" bgcolor="white"> 
<p><FONT size=2><br><IMG height=9 alt=dia_bluve.gif 
src="http://www.sohomart4u.com/newmarketing/img/dec1.gif" width=30 border=0>원치않는 
정보였다면 머리숙여 사과의 말씀을 올립니다.<BR><IMG height=9 alt=dia_bluve.gif 
src="http://www.sohomart4u.com/newmarketing/img/dec1.gif" width=30 border=0>본메일은 
발신전용 메일입니다.<BR><IMG height=9 alt=dia_bluve.gif 
src="http://www.sohomart4u.com/newmarketing/img/dec1.gif" width=30 border=0>본 
메일은 정보통신부 권고사항에 의거하여 발송된 광고메일입니다.<BR><IMG height=9 alt=dia_bluve.gif 
src="http://www.sohomart4u.com/newmarketing/img/dec1.gif" width=30 border=0>귀하의 
메일은 메일수집 프로그램을 사용하여 추출하였으며, 메일주소 이외에 <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;어떠한 정보도 가지고 있지 않습니다. <B><A 
href="mailto:ad...@so...?subject=수신을 거부합니다">수신을 거부하실 분은 여기를 클릭</A></B>하여 주십시요.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;혹여 클릭이 되지 않으시면 <A 
href="mailto:ad...@so...?subject=수신을 거부합니다">ad...@so...</A> 
으로 보내주시면 됩니다.<BR></FONT></p> 
<P align=center><FONT size=2>If you want to be removed from our recipient list, 
please click <A 
href="mailto:ad...@so..."><B>[unsubscribe]</B></A>.&nbsp;</FONT></P></td> 
</tr> 
</table> 
<p>;<IMG 
src="http://sohonuri.com/supercounter/count.cgi?sohomart4u==http://www.sohomart4u.com"></p> 
</body> 
</html>

[Linux-NTFS-Dev] New Records

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

Hi Everyone,

It's not quite the end of the month, but we've already hit a *great*
milestone.  Today we have a new record for monthly downloads AND we've
smashed through the 100K pages barrier!  YEAH!

2000 November        80       0
2000 December        39       0
2001 January        130       0
2001 February     3,077     608
2001 March        1,555     131
2001 April        3,136     905
2001 May          3,074     986
2001 June         9,535   3,194
2001 July        11,135   4,029
2001 August      13,667   4,739
2001 September   15,488   4,912
2001 October     15,984   5,414
2001 November    29,510   8,374
2001 December    24,663   6,031
2002 January     35,097  10,664
2002 February    29,048   7,235
2002 March       44,275   8,612
2002 April       54,277   7,638
2002 May         66,773   9,291
2002 June        59,719   7,372
2002 July        70,956   6,980
2002 August      75,256   6,315
2002 September   82,069   5,059
2002 October     99,133   6,953
2002 November   100,407  10,694

http://sf.net/project/stats/index.php?report=months&group_id=13956

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

WWW: http://linux-ntfs.sf.net
IRC: #ntfs on irc.freenode.net 

Re: [Linux-NTFS-Dev] *fdisk + resize + SI prefixes

[Szakacsits S. <sz...@si...>]

On Mon, 25 Nov 2002, Andrew Clausen wrote:
> On Sun, Nov 24, 2002 at 04:53:17PM +0100, Szakacsits Szabolcs wrote:
> > IMPORTANT: When recreating the partition, make sure you
> >   3)  do not make it smaller than the new NTFS filesystem size
>
> Doesn't it have to be exactly the same size for NTFS?
> (It does for fat, btw!)

Luckily no. The first waves of FAQ were, "Windows shows reduced
filesystem but the partition is the same size." (There was one report
on this list also).

Moreover there is a copy of the NTFS boot sector in the last sector of
the NTFS partition that isn't really part of the NTFS filesystem. So
to shrink an NTFS partition with two utils (fs + partition resizer)
three steps would be needed assuming ntfsresize doesn't know where
the user will exactly shrink the partition:
  1) shrink ntfs filesystem to size N
  2) shrink ntfs partition to size M where M > N
  3) create the ntfs backup boot sector at the partition end

This would be a bit too complex and error-prone for most users. How is
it solved? Since ntfs consistency check is always scheduled by
ntfsresize when user boots Windows that also restores the backup boot
sector, it's not needed to care about it anymore. ntfsresize also
creates a bit slightly smaller filesystem reserving space for the
backup boot sector thus the user can safely just do the usual
  1) shrink ntfs filesystem to size N
  2) shrink ntfs partition to size N

> > IMPORTANT: When recreating the partition, make sure you
> >   1)  create it with the same starting disk cylinder
[...]
> > I guess Parted ensures all, right? [you already answered some, yes]
>
> yes.  Well, (1) no if parted has been misinformed of the CHS
> geometry. (Motivation: in some cases, Parted will have to change
> the start, and "keeping the same" isn't a good solution here)

OK, can we forget about the unreliable CHS? Same starting sector [for
filesystem boot sector] with the restriction filesystem start can not
change?

	Szaka

Re: [Linux-NTFS-Dev] *fdisk + resize + SI prefixes

[Andrew C. <cl...@gn...>]

On Sun, Nov 24, 2002 at 04:53:17PM +0100, Szakacsits Szabolcs wrote:
> > Just thought I'd comment on the situation with Parted.
> > If you resize a file system that Parted supports directly, then
> 
> You mean, if one resizes a partition that has a filesystem that Parted
> supports directly?

yep

> > (It's one of the arguments in favour of coupling a fs interface with
> > a partition one)
> 
> Definitely. It's not by accident ntfsresize finishes like this,
> ---------------------------------------------------------------->
> NTFS had been successfully resized on device '/dev/hda1'.
> You can go on to resize the device e.g. with 'fdisk'.
> IMPORTANT: When recreating the partition, make sure you
>   1)  create it with the same starting disk cylinder
>   2)  create it with the same partition type (usually 7, HPFS/NTFS)
>   3)  do not make it smaller than the new NTFS filesystem size

Doesn't it have to be exactly the same size for NTFS?
(It does for fat, btw!)

>   4)  set the bootable flag for the partition if it existed before
> Otherwise you may lose your data or can't boot your computer from the disk!
> <---------------------------------------------------------------
> 
> I guess Parted ensures all, right? [you already answered some, yes]

yes.  Well, (1) no if parted has been misinformed of the CHS
geometry.  (Motivation: in some cases, Parted will have to change
the start, and "keeping the same" isn't a good solution here)

Cheers,
Andrew

Re: [Linux-NTFS-Dev] *fdisk + resize + SI prefixes

[Szakacsits S. <sz...@si...>]

On Sun, 24 Nov 2002, Andrew Clausen wrote:

> Just thought I'd comment on the situation with Parted.
> If you resize a file system that Parted supports directly, then

You mean, if one resizes a partition that has a filesystem that Parted
supports directly?

> obviously the constraint solver will make sure everything fits :)

I hoped so ;)

> (It's one of the arguments in favour of coupling a fs interface with
> a partition one)

Definitely. It's not by accident ntfsresize finishes like this,
---------------------------------------------------------------->
NTFS had been successfully resized on device '/dev/hda1'.
You can go on to resize the device e.g. with 'fdisk'.
IMPORTANT: When recreating the partition, make sure you
  1)  create it with the same starting disk cylinder
  2)  create it with the same partition type (usually 7, HPFS/NTFS)
  3)  do not make it smaller than the new NTFS filesystem size
  4)  set the bootable flag for the partition if it existed before
Otherwise you may lose your data or can't boot your computer from the disk!
<---------------------------------------------------------------

I guess Parted ensures all, right? [you already answered some, yes]

> (2) rm and rescue.  Rescue works like gpart.  (Looks at
> signatures/superblocks, and figures out where everything should be)

Very nice :)

	Szaka

[Linux-NTFS-Dev] Re: *fdisk + resize + SI prefixes

[Szakacsits S. <sz...@si...>]

On Sat, 23 Nov 2002 And...@cw... wrote:

> >                     k        M          G
> > fdisk             2^10     2^20      10^3*2^20
>
> OK, I just changed fdisk. So from the next util-linux release on
> it will be
>
>     fdisk           10^3     10^6       10^9

I made a patch for ntfsresize to also use decimal units. Besides I
documented it [most utils don't do it that can also confuse users].

	Szaka

Re: [Linux-NTFS-Dev] *fdisk + resize + SI prefixes

[Andrew C. <cl...@gn...>]

On Sat, Nov 23, 2002 at 10:45:22PM +0100, And...@cw... wrote:
> > In Parted, I plan to change the interface to allow arbitary
> > units to be expressed.
> 
> I hesitated for a second in fdisk, and decided that there
> is no reason to support binary units. More choice means
> more user confusion, so should be added only when it really
> adds new power.

Good point.  OTOH, percentages (of disk size) might be a useful unit.
Also, k vs m.

> > I'd rather not confuse users in the mean time.
> > Do you think I should?
> 
> No. A megabyte is always 1000000 bytes. Keep life simple.

So, you're basically arguing: "since you're going to scrap
2^x units, there's no advantage to scrapping them later".

I'm convinced.

Thanks,
Andrew