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

[Linux-NTFS-Dev] Geometry determination

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

Hi all,

I have been experimenting a little with what Windows / Linux 2.4 / Linux
2.6 think the geometry of a couple of HDs is and the results are not
very promising.  )-:

Using Linux 2.4, HDIO_GETGEO ioctl, I get the same Heads and Sectors per
Track as Windows on both HDs I tried it on.  This is the good news. 
I.e. at least on those two disks mkntfs as it stands now would create
Windows bootable partitions.

The bad news is that Linux 2.4, HDIO_GETGEO ioctl returns wrong values
for both HDs.  (It said Heads were 16 both time when Linux 2.4 said 255
for one of the HDs and 128 for the other.)

So while mkntfs will work at the moment in a few months/years time it
will probably never work any more without user specified geometry.  )-:

I have unfortunately not found _any_ way to get the values returned by
Linux 2.4 / Windows on a Linux 2.6 system and I tried looking in
/proc/ide, using hdparm, and using .  )-:

This is very annoying to say the least.  )-:

Any ideas?

Of course, this all might have been coincidence and someone else testing
a different set of two HDs might find the opposite.

What we really want to know is how Windows determines the geometry? 
Anyone know?

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] Re: ntfsprogs 1.9.1 plans?

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

On Mon, 2004-03-29 at 12:48, Szakacsits Szabolcs wrote:
> I also [re]realised ntfsclone does a lot of needless lseek(2)'s and
> probably that triggers the EIO problem in smbfs or XP's network share
> implementation. I'm going to fix this also ASAP.

Cool.

> Moreover I've got French and Finnish traslations of ntfsresize.8.in. It
> would be very nice to integrate them into ntfsprogs. What do you think? 

Great!

> Do you know how to do this properly nowadays (I'm not too up-to-date) or
> should I do it? I'd do it happily but that might take time also

I haven't the faintest idea how internationalisation of any shape or
form works so please feel free to do it yourself (or get someone else to
do it)...

If you need build system / configure.ac / whatever modifications please
let me know what you need and I will do it so the build stays with SUSE
9.1 build system...  Thanks.

> Of course we wouldn't refuse anybody else's help, actually just the 
> opposite ;)

Indeed.  (-:

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] Re: ntfsprogs 1.9.1 plans?

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

On Fri, 26 Mar 2004, Anton Altaparmakov wrote:

> Sure.  I won't release it until you are finished.  If I get desperate to
> release it I will let you know...  (-:

:) 
 
I also [re]realised ntfsclone does a lot of needless lseek(2)'s and
probably that triggers the EIO problem in smbfs or XP's network share
implementation. I'm going to fix this also ASAP.

Moreover I've got French and Finnish traslations of ntfsresize.8.in. It
would be very nice to integrate them into ntfsprogs. What do you think? 
Do you know how to do this properly nowadays (I'm not too up-to-date) or
should I do it? I'd do it happily but that might take time also (I have
50+ NTFS related unanswered/unsettled emails + dozens todo items).

Of course we wouldn't refuse anybody else's help, actually just the 
opposite ;)

Cheers,
	Szaka

[Linux-NTFS-Dev] Re: ntfsprogs 1.9.1 plans?

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

Hi Szaka,

On Fri, 2004-03-26 at 07:52, Szakacsits Szabolcs wrote:
> You mentioned some days ago that you're going to release 1.9.1. What's the
> current plan?

None, really.  (-;

> Before that I'd like to add some minor smbfs related diagnostic code,
> messages, doc to ntfsclone and I'd schedule it accordingly, for the 
> reason to reduce user confusion, frustration, repeated questions.

Sure.  I won't release it until you are finished.  If I get desperate to
release it I will let you know...  (-:

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] ntfsprogs 1.9.1 plans?

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

Hello Anton,

You mentioned some days ago that you're going to release 1.9.1. What's the
current plan?

Before that I'd like to add some minor smbfs related diagnostic code,
messages, doc to ntfsclone and I'd schedule it accordingly, for the 
reason to reduce user confusion, frustration, repeated questions.

Thanks,
	Szaka

[Linux-NTFS-Dev] Re: smbfs large file (2GB+) support problem

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

On Tue, 23 Mar 2004, Szakacsits Szabolcs wrote:
> 
> > >   3) There are LFS (large file support = 2 GB+) problems with smbfs. 
> > >      Details are here: 
> > > 
> > > 	http://sf.net/forum/forum.php?thread_id=1043909&forum_id=44085
> > > 
> > >      Kernel 2.6 and 2.4.25 should support smbfs LFS but it seems it's
> > >      buggy. Apparently it sends a slightly wrong request then XP or samba
> > >      3.0 do create (ftruncate) the large file but they answer with "wrong
> > >      parameters" what smbfs interprets as EFBIG (File too large). 

The solution is, apparently, using the 'lfs' option during [smb]mount.
Pretty insane. However I couldn't find any relevant option yet in vanilla
2.4.25 kernel (I didn't check 2.6 yet).

But there is a new smbfs problem. The kernel implementation can't really
handle large file transfers reliable and sometimes gives EIO in the middle
of the transfer. Duh.

	Szaka

Re: [Linux-NTFS-Dev] Re: Snapshot compilation problem

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

On Thu, 25 Mar 2004, Anton Altaparmakov wrote:

> > No bk export? Then it's VERY dangerous.
> No, the bk export is still there.  I said "instead of the autogen.sh", so

I see, sorry.

> > autoreconf also seems to be a workaround for a bug (inconsistency) that
> > you, and only you, have in your tree. For me it seems during the autotools
> > upgrade things got mixed up. Or SUSE 9.1 BETA autotools are buggy and in
> > that case you should report ;)
> 
> What do you mean?  What inconsistency?

IMHO autogen.sh should also create a compilable package. 

> Note that autogen.sh does autoreconf followed by ./configure, nothing
> else...

Exactly. Fundamentally both do the same, but only the last one works.
That's what I don't get.

	Szaka

Re: [Linux-NTFS-Dev] Re: Snapshot compilation problem

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

On Thu, 25 Mar 2004, Szakacsits Szabolcs wrote:
> On Thu, 25 Mar 2004, Anton Altaparmakov wrote:
> > There is now a new snapshot with this fixed.  At least works for me on
> > a RH9-ish box.
>
> This compiles, thanks.
>
> > The way I generated snapshots was (all scripted of course):
> >
> > bk export
> > cd to exported dir
> > edit configure.ac to add date to version number
> > ./autogen.sh
> > make distclean
> > tar
> > scp to sf.net
> > ssh to sf.net and run bin/add-snapshot
> >
> > This fails as you saw for me too unless I have the autoconf 2.59
> > installed.
> >
> > The new script does instead of the autogen.sh this:
> >
> > autoreconf --verbose --install --warnings=all
> > ./configure
> > make libs
> > make
> > make extra
> > and then carries on with make distclean, etc.
> >
> > This seems to work fine now.
>
> No bk export? Then it's VERY dangerous.

No, the bk export is still there.  I said "instead of the autogen.sh", so
the full script now does:

bk export
cd to exported dir
edit configure.ac to add date to version number
autoreconf --verbose --install --warnings=all
./configure
make libs
make
make extra
make distclean
tar
scp to sf.net
ssh to sf.net and run bin/add-snapshot

> autoreconf also seems to be a workaround for a bug (inconsistency) that
> you, and only you, have in your tree. For me it seems during the autotools
> upgrade things got mixed up. Or SUSE 9.1 BETA autotools are buggy and in
> that case you should report ;)

What do you mean?  What inconsistency?

The only reason I am running autoreconf is that I modify the version in
configure.ac and autoreconf takes configure.ac and generates configure
from it which is needed otherwise the version number in configure is not
changed...

Note that autogen.sh does autoreconf followed by ./configure, nothing
else...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] Re: Snapshot compilation problem

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

On Thu, 25 Mar 2004, Anton Altaparmakov wrote:
> There is now a new snapshot with this fixed.  At least works for me on
> a RH9-ish box.

This compiles, thanks.
 
> The way I generated snapshots was (all scripted of course):
> 
> bk export
> cd to exported dir
> edit configure.ac to add date to version number
> ./autogen.sh
> make distclean
> tar
> scp to sf.net
> ssh to sf.net and run bin/add-snapshot
> 
> This fails as you saw for me too unless I have the autoconf 2.59
> installed.
> 
> The new script does instead of the autogen.sh this:
> 
> autoreconf --verbose --install --warnings=all
> ./configure
> make libs
> make
> make extra
> and then carries on with make distclean, etc.
> 
> This seems to work fine now.

No bk export? Then it's VERY dangerous. 

Imagine you have some write (or whatever) related experimental code in
your own tree (quite possible IMHO :) and you can pack and release it
accidently without realising. It would be extremely hard later to track
down that the released package was different than the one thought to be
released!

autoreconf also seems to be a workaround for a bug (inconsistency) that
you, and only you, have in your tree. For me it seems during the autotools
upgrade things got mixed up. Or SUSE 9.1 BETA autotools are buggy and in
that case you should report ;) 

	Szaka

Re: [Linux-NTFS-Dev] Re: Snapshot compilation problem

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

On Thu, 25 Mar 2004, Szakacsits Szabolcs wrote:
> On Wed, 24 Mar 2004, Szakacsits Szabolcs wrote:
> > On Wed, 24 Mar 2004, Anton Altaparmakov wrote:
> > > On Wed, 24 Mar 2004, Szakacsits Szabolcs wrote:
> > > > I just tried the latest snaphot ntfsprogs-200403241351.tar.bz2
> > > > and I couldn't compile it:
> > > >
> > > >   ./configure
> > > >     [... no error ...]
> > > >   make
> > > >   cd . && /bin/sh /ntfsprogs/missing --run autoheader
>
> Perhaps a (few) step was missed during packing? Strangely I don't have
> compilation problem using BK, only with the source snapshot.

There is now a new snapshot with this fixed.  At least works for me on
a RH9-ish box.

The way I generated snapshots was (all scripted of course):

bk export
cd to exported dir
edit configure.ac to add date to version number
./autogen.sh
make distclean
tar
scp to sf.net
ssh to sf.net and run bin/add-snapshot

This fails as you saw for me too unless I have the autoconf 2.59
installed.

The new script does instead of the autogen.sh this:

autoreconf --verbose --install --warnings=all
./configure
make libs
make
make extra
and then carries on with make distclean, etc.

This seems to work fine now.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] Re: $LogFile state (was: Re: Crash dumps go to pagefile.sys)

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

On Thu, 25 Mar 2004, Szakacsits Szabolcs wrote:
> On Wed, 24 Mar 2004, Anton Altaparmakov wrote:
> > Really, the only way is to scan $LogFile to determine the state.  If the
> > log is fully check pointed and no uncommitted transactions are remaining
> > it means the volume is clean.  And otherwise it means it is dirty.  I
> > have been planning to implement this in ntfsprogs (and in the kernel for
> > that matter) but haven't had time as it is rather a lot of work.
>
> Why is it a lot of work? Unknown?
>
> Just a "clean" or "dirty" answer would be enough. No need to redo or
> undo the log/update records.

Oh, of course.  I have absolutely no intention of implementing redo/undo
of the journal.  Or at least not until we have a complete ntfs rw library
and driver, then maybe I will look into it but otherwise no way...

The difficulty is that there is no single bit saying "journal clean" or
"journal dirty".  You have to actually parse the entirety of $LogFile
reading every single record, parsing each of them, and finding the last
written record.  Then you have to backtrace what you did till you find the
last checkpointed record and then I am not too sure.  Probably something
along the lines of "if any records requiring undo or redo are present
after the last checkpoint record assume journal is dirty otherwise assume
it is clean".  When we find it is clean we then proceed to empty the
journal as we do now so that a Windows boot doesn't gratuitously perform a
redo pass on us and corrupt something.

This is a lot of code most of which requires existing $LogFile analysis
and further reverse engineering.

This is not a piece of cake...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] $LogFile state (was: Re: Crash dumps go to pagefile.sys)

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

On Wed, 24 Mar 2004, Anton Altaparmakov wrote:
> Really, the only way is to scan $LogFile to determine the state.  If the
> log is fully check pointed and no uncommitted transactions are remaining
> it means the volume is clean.  And otherwise it means it is dirty.  I
> have been planning to implement this in ntfsprogs (and in the kernel for
> that matter) but haven't had time as it is rather a lot of work.

Why is it a lot of work? Unknown? 

Just a "clean" or "dirty" answer would be enough. No need to redo or
undo the log/update records.

I think this would be the most important next step to solve.

> > I thought the VOLUME_IS_DIRTY flag is supposed to mark this. I checked it
> > out and it doesn't. After a crash it isn't set. Apparently it isn't even
> > set when NTFS is mounted.
> I think it does but I think it is only set while data is being actively
> written to disk (I may well be wrong though).

So we could check VOLUME_IS_DIRTY and $LogFile then mount only if none is
dirty.

	Szaka

Re: [Linux-NTFS-Dev] Re: Snapshot compilation problem

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

On Wed, 24 Mar 2004, Szakacsits Szabolcs wrote:
> On Wed, 24 Mar 2004, Anton Altaparmakov wrote:
> > On Wed, 24 Mar 2004, Szakacsits Szabolcs wrote:
> > > I just tried the latest snaphot ntfsprogs-200403241351.tar.bz2
> > > and I couldn't compile it:
> > >
> > >   ./configure
> > >     [... no error ...]
> > >   make
> > >   cd . && /bin/sh /ntfsprogs/missing --run autoheader

Perhaps a (few) step was missed during packing? Strangely I don't have
compilation problem using BK, only with the source snapshot.

> > Hm.  The only thing I can think of is to try to rm -rf autom4te.cache or
> > whatever the directory is called and then try running ./configure again.

That was the first I checked. Didn't help.

> > I am not sure why it is trying to run the autotools again...
> Ok, I'll take a look tomorrow (if nobody figures out by that time).

The 'make' failed the same way also on the other distros I tried. I don't
have susu 9.1 beta and I'm afraid that's needed to track it down. Maybe on
the suse beta list somebody can help?

	Szaka

Re: [Linux-NTFS-Dev] Re: Snapshot compilation problem

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

On Wed, 24 Mar 2004, Anton Altaparmakov wrote:
> On Wed, 24 Mar 2004, Szakacsits Szabolcs wrote:
> > I just tried the latest snaphot ntfsprogs-200403241351.tar.bz2
> > and I couldn't compile it:
> >
> >   ./configure
> >     [... no error ...]
> >   make
> >   cd . && /bin/sh /ntfsprogs/missing --run autoheader
> >   configure.ac:24: error: Autoconf version 2.59 or higher is required
> >   configure.ac:24: the top level
> >   autom4te: /usr/bin/m4 failed with exit status: 1
> >   autoheader: /usr/bin/autom4te failed with exit status: 1
> >   make: *** [config.h.in] Error 1
> 
> Hm.  The only thing I can think of is to try to rm -rf autom4te.cache or
> whatever the directory is called and then try running ./configure again.
> 
> I am not sure why it is trying to run the autotools again...

Ok, I'll take a look tomorrow (if nobody figures out by that time).

	Szaka

[Linux-NTFS-Dev] Re: Snapshot compilation problem

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

Hi Szaka,

On Wed, 24 Mar 2004, Szakacsits Szabolcs wrote:
> I just tried the latest snaphot ntfsprogs-200403241351.tar.bz2
> and I couldn't compile it:
>
>   ./configure
>     [... no error ...]
>   make
>   cd . && /bin/sh /ntfsprogs/missing --run autoheader
>   configure.ac:24: error: Autoconf version 2.59 or higher is required
>   configure.ac:24: the top level
>   autom4te: /usr/bin/m4 failed with exit status: 1
>   autoheader: /usr/bin/autom4te failed with exit status: 1
>   make: *** [config.h.in] Error 1

Hm.  The only thing I can think of is to try to rm -rf autom4te.cache or
whatever the directory is called and then try running ./configure again.

I am not sure why it is trying to run the autotools again...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] Snapshot compilation problem

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

Hello Anton,

I just tried the latest snaphot ntfsprogs-200403241351.tar.bz2
and I couldn't compile it:

  ./configure
    [... no error ...]
  make
  cd . && /bin/sh /ntfsprogs/missing --run autoheader
  configure.ac:24: error: Autoconf version 2.59 or higher is required
  configure.ac:24: the top level
  autom4te: /usr/bin/m4 failed with exit status: 1
  autoheader: /usr/bin/autom4te failed with exit status: 1
  make: *** [config.h.in] Error 1

	Szaka

Re: [Linux-NTFS-Dev] Crash dumps go to pagefile.sys (was: pagefile.sys location and usage)

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

On Wed, 2004-03-24 at 14:03, Szakacsits Szabolcs wrote:
> On Mon, 1 Mar 2004, Szakacsits Szabolcs wrote:
> 
> > Might pagefile.sys has data used between reboots, as sometimes Linux swap?
> 
> Veteran Microsoft engineer writes to his blog at
>   
>   http://blogs.msdn.com/larryosterman/archive/2004/03/18/92010.aspx
> 
>   Nowadays, NT doesn't always write the entire contents of memory out -
>   it's controlled by a setting in the Startup and Recovery settings dialog
>   on the Advanced tab of the system control panel applet - there are 4
>   choices - None, a small "minidump", a Kernel memory dump and a full
>   memory dump. Only the full memory dump will write all of RAM, the others
>   limit the amount of memory that's written out. But it still goes to the
>   paging file.
> 
> Of course I believe when I checked it out, although I suspected this. 
> And since there is this often used thus robust feature then perhaps 
> it's also used in other cases ...

Possible.  Certainly, now we know that we really should always copy the
pagefile in ntfsclone, too...

> This also lead again to a very important question: how do we know if
> Windows crashed and NTFS is dirty? 

Really, the only way is to scan $LogFile to determine the state.  If the
log is fully check pointed and no uncommitted transactions are remaining
it means the volume is clean.  And otherwise it means it is dirty.  I
have been planning to implement this in ntfsprogs (and in the kernel for
that matter) but haven't had time as it is rather a lot of work.

> I thought the VOLUME_IS_DIRTY flag is supposed to mark this. I checked it
> out and it doesn't. After a crash it isn't set. Apparently it isn't even
> set when NTFS is mounted.

I think it does but I think it is only set while data is being actively
written to disk (I may well be wrong though).

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] hidden secctors and NTFS

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

On Wed, 24 Mar 2004, Anton Altaparmakov wrote:

> Ah.  I did have that coded but I changed it before committing it after
> reading the latest TestDisk release notes from which I gathered that at
> least FreeBSD uses separate ioctls to get each value so I decided to

I see ... Other platforms can have also their own versions ...

> Do you still think it should be a single ntfs_device_geometry_get()
> function?  If yes then I would be willing to switch to that again -
> shame I didn't checkin the code before changing it as I will need to
> redo it from scratch...  )-:

Don't bother. Now it make sense for me also.
 
> > BTW, do we still need the ntfsprogs-devel tree? As I've seen, only I
> I was only keeping it for you and am very happy to get rid of it.  (-:

:) Cool, me too :)) It did his job but we must move along.

	Szaka

[Linux-NTFS-Dev] Crash dumps go to pagefile.sys (was: pagefile.sys location and usage)

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

On Mon, 1 Mar 2004, Szakacsits Szabolcs wrote:

> Might pagefile.sys has data used between reboots, as sometimes Linux swap?

Veteran Microsoft engineer writes to his blog at
  
  http://blogs.msdn.com/larryosterman/archive/2004/03/18/92010.aspx

  Nowadays, NT doesn't always write the entire contents of memory out -
  it's controlled by a setting in the Startup and Recovery settings dialog
  on the Advanced tab of the system control panel applet - there are 4
  choices - None, a small "minidump", a Kernel memory dump and a full
  memory dump. Only the full memory dump will write all of RAM, the others
  limit the amount of memory that's written out. But it still goes to the
  paging file.

Of course I believe when I checked it out, although I suspected this. 
And since there is this often used thus robust feature then perhaps 
it's also used in other cases ...

This also lead again to a very important question: how do we know if
Windows crashed and NTFS is dirty? 

I thought the VOLUME_IS_DIRTY flag is supposed to mark this. I checked it
out and it doesn't. After a crash it isn't set. Apparently it isn't even
set when NTFS is mounted.

	Szaka

Re: [Linux-NTFS-Dev] hidden secctors and NTFS

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

On Wed, 2004-03-24 at 13:30, Szakacsits Szabolcs wrote:
> On Tue, 23 Mar 2004, Anton Altaparmakov wrote:
> I see you made the changes but I think it could have been simpler by 
> just using the similar interface, e.g. ntfs_device_geometry_get(), what
> HDIO_GETGEO uses. Now basicaly the same code is copy-pasted into three
> functions and only the return statement is different. It's more trouble 
> to maintain and more trouble to use them.

Ah.  I did have that coded but I changed it before committing it after
reading the latest TestDisk release notes from which I gathered that at
least FreeBSD uses separate ioctls to get each value so I decided to
maek separate calls, too.  Otherwise we would need to test each of the
results for success even if the function was successful or alternatively
we would alsways have to fail the function even if we can actually
supply some (but not all) of the values automatically.

Do you still think it should be a single ntfs_device_geometry_get()
function?  If yes then I would be willing to switch to that again -
shame I didn't checkin the code before changing it as I will need to
redo it from scratch...  )-:

> I have a request also, please make a source snapshot (last one was a week
> ago). 

Done.

> BTW, do we still need the ntfsprogs-devel tree? As I've seen, only I used
> it, it was just extra work for you to maintain (thanks!) but I don't need
> it anymore. Now it's also just extra work for me. So if nobody really
> needs it we could just delete it? If there is need in the future by
> somebody then we could still recreate it.

I was only keeping it for you and am very happy to get rid of it.  (-:

<clicketyclick>

It's now gone!  (-:

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] hidden secctors and NTFS

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

On Tue, 23 Mar 2004, Anton Altaparmakov wrote:

> > On boot partitions these values need to be really set to what the actual
> > Windows boot code expects. Otherwise it can't load the next boot stages
> > from the disk and boot just hangs.
>
> Ok.  )-:  Thanks for trying though!

I see you made the changes but I think it could have been simpler by 
just using the similar interface, e.g. ntfs_device_geometry_get(), what
HDIO_GETGEO uses. Now basicaly the same code is copy-pasted into three
functions and only the return statement is different. It's more trouble 
to maintain and more trouble to use them.

I have a request also, please make a source snapshot (last one was a week
ago). 

BTW, do we still need the ntfsprogs-devel tree? As I've seen, only I used
it, it was just extra work for you to maintain (thanks!) but I don't need
it anymore. Now it's also just extra work for me. So if nobody really
needs it we could just delete it? If there is need in the future by
somebody then we could still recreate it.

	Szaka

Re: [Linux-NTFS-Dev] hidden secctors and NTFS

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

On Tue, 2004-03-23 at 23:47, Szakacsits Szabolcs wrote:
> On Tue, 23 Mar 2004, Anton Altaparmakov wrote:
> > Could you try just one thing more?  Place 0xffff into both heads and
> > sectors_per_track.  
> 
> It doesn't work. 
> 
> On boot partitions these values need to be really set to what the actual
> Windows boot code expects. Otherwise it can't load the next boot stages
> from the disk and boot just hangs.

Ok.  )-:  Thanks for trying though!

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
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] Re: SysRescCd-0.2.12 released

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

On Tue, 23 Mar 2004, [ISO-8859-1] François Dupoux wrote:

> SystemRescueCd-0.2.12 is released as a copy of 0.2.12_RC2.

Thanks! :) I updated the ntfsresize faq page at

	http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

 "New SystemRescueCd released. It has the latest QTParted, the latest
  Parted and the latest ntfsresize with stable data relocation
  support. Today this is the easiest and most powerful open source way 
  to resize any of those 300+ million NTFS partitions non-destructively! 
  Here are the steps how to do it: ..."

Congratulations to everybody!

Personally I think this was a very important thing to get done as soon as
possible in open source: today 60+% of the computer users have a Windows
variant using NTFS and in some years this will be even higher. When people
consider alternatives, the majority wants an easy, stable, free and
non-destructive way to install the new system(s) alongside the old one.

This isn't an issue anymore!

Again, good job! I'm proud I could work with all of you :)

Cheers,
	Szaka

Re: [Linux-NTFS-Dev] hidden secctors and NTFS

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

On Tue, 23 Mar 2004, Anton Altaparmakov wrote:
> Could you try just one thing more?  Place 0xffff into both heads and
> sectors_per_track.  

It doesn't work. 

On boot partitions these values need to be really set to what the actual
Windows boot code expects. Otherwise it can't load the next boot stages
from the disk and boot just hangs.

	Szaka

Re: [Linux-NTFS-Dev] hidden secctors and NTFS

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

On Tue, 23 Mar 2004, Anton Altaparmakov wrote:
> Could you try just one thing more?  Place 0xffff into both heads and
> sectors_per_track.  If that works, try doing the same with hidden_sectors
> (obviously 32bit there).  I am curios as to whether this will work...

OK, I think I have time for that :) Just a moment ... (last famous words :)

	Szaka