Re: How to get started

Arend Lammertink <[email protected]> Mon, 1 Dec 2003 15:24:55 +0100
Newsgroups gmane.linux.debian.ports.windows
Message-ID <[email protected]>
On Sunday 30 November 2003 22:04, Junichi Uekawa wrote:
> > > Windows applications use the chance of rebooting to copy files
> > > that are previously used; thus dpkg and apt will probably
> > > need to use Windows reboots to get applications upgraded.
> >
> > Yes, but only if the file is open in the first place.  Perhaps a spec=
ial
> > dpkg binary that executes on reboot that moves files from a temporary
> > folder to the installation location.  It could either be registered t=
o
> > always run or registered to run and remove itself from the registry.
>
> Note that most of the time, surprisingly many files are actually open.
> All the currently executing executables are 'open files'.

I guess renaming an open file is also not possible?


Perhaps dpkg could run with it's own separate set of executables. I guess=
 it=20
won't need much more then dpkg itself, a shell, tar, gzip.=20
So, you could make a dkpg-sys directory that is only used by dpkg, so tha=
t=20
dpkg can update at least the rest of the system.

Of course, that would require closing all your applications while upgradi=
ng.

The next idea that comes to mind is using symlinks. So, instead of having=
 a=20
sh.exe, you would have a sh.version.exe and a symlink to the latest versi=
on.
Since the symlink would not be open (would it???), it could be replaced.
However, this would be ugly, too.

But, how about using another filesystem, like ext2/3?
There are ext2 drivers available for win32, like=20
http://winext2fsd.sourceforge.net/ ,=20
http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm and http://sys.xiloo.c=
om/=20
/ http://sourceforge.net/projects/ext2fsd .

Could that filesystem be the answer?

Let's assume for a moment we would be using a samba mount as a file syste=
m.=20
We would be sure the remote system would have no problem replacing a file=
=20
that is in-use. Would win32 complain about replacing locally open files o=
n=20
such a remote filesystem?
In other words: are we facing a limitation of the OS itself, or is it 'ju=
st'=20
a matter of chosing the right filesystem?

In case a different filesystem would be the answer, which fs should we ch=
oose?
I guess a fs that could be shared between win32/Linux would be ideal.

Regards,

-- Arend --


--=20
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]=
.org