Re: [Freedos-kernel] patch for the rename function, please check
Hi Eric,
2007/9/19 Eric Auer e...@coli.uni-sb.de:
I tried to fix bug 1908: Our kernel used to need a fresh
dir entry for renaming, as it renamed by create new dir
entry for file, then mark old entry as deleted. My patch
tries to limit this to cases where you rename files or
directories across directories. If both old and new name
are in the same directory, the new version should only
change the old dir entry in place. So that should even
work if you rename files on a disk with full root dir...
I got a zero-sized file when I tried to save the attachment of
archived bug 1908,
www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1908
www.freedos.org/bugzilla/cgi-bin/attachment.cgi?id=43
but I've changed dos_rename in SVN r1417 to change the directory entry
in-place instead of creating a new one and then deleting the old one
-- if the directory is the same for both paths.
Caveats:
- it is possible that renaming directories on a disk with
full root directory still does consume an extra dir entry,
as I am not sure whether my does the rename take place in
the same directory test captures that case as well.
I don't think that's a problem: then we have
fnp1-f_dirstart == fnp2-f_dirstart == 0
- if you rename a directory across directories, then the
.. entry for the directory itself is not updated. Note
that neither FreeCOM command.com nor MOVE use the int21
rename interface for such activities at the moment (?).
I think MSDOS specifically disallows this:
http://groups.google.com/group/comp.os.msdos.programmer/msg/259ca094fe4d0c9a
so we need to add another check.
- if ((ret = remove_lfn_entries(fnp1)) 0)
- return ret;
+ if ((ret = remove_lfn_entries(fnp1)) 0) {
+ dir_close(fnp2);
+ return ret; /* remove_... already closes fnp1 on error */
+ }
With my recent fnode changes (I'll send another email) we no longer
need to close fnodes: there are only two at fixed locations and
usually only the first is used. The only exception being
dos_rename() which uses the two fnodes. So it saves some trouble
with leaks.
Bart
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] patch for the rename function, please check
Hi all,
I tried to fix bug 1908: Our kernel used to need a fresh
dir entry for renaming, as it renamed by create new dir
entry for file, then mark old entry as deleted. My patch
tries to limit this to cases where you rename files or
directories across directories. If both old and new name
are in the same directory, the new version should only
change the old dir entry in place. So that should even
work if you rename files on a disk with full root dir...
Caveats:
- it is possible that renaming directories on a disk with
full root directory still does consume an extra dir entry,
as I am not sure whether my does the rename take place in
the same directory test captures that case as well.
- if you rename a directory across directories, then the
.. entry for the directory itself is not updated. Note
that neither FreeCOM command.com nor MOVE use the int21
rename interface for such activities at the moment (?).
I would really appreciate if some experts (Bart, Arkady,
Jeremy, Tom, ...?) could have a look at my patch. It does
seem to work, but it is hard to know for sure I would say.
Note:
- if ((ret = remove_lfn_entries(fnp1)) 0)
-return ret;
+ if ((ret = remove_lfn_entries(fnp1)) 0) {
+dir_close(fnp2);
+return ret; /* remove_... already closes fnp1 on error */
+ }
This sub-patch is supposed to fix a fnode leak, and it
is not related to the primary purpose of my patch, the
be able to rename without consuming dir entries one.
Thanks for having a look :-)
The bug description is here:
www.freedos.org/bugzilla/cgi-bin/show_bug.cgi?id=1908
From there, you can follow the link to my patch:
www.freedos.org/bugzilla/cgi-bin/attachment.cgi?id=43
Eric
PS: Current major kernel bugs are
1658 norton ghost failure on 2029+ (??)
1842 dos=high fails in beta9sr2 (??)
1862 subst troubles (fixed in SVN revision 1357?)
1902 ren fails on full disk (fixed by my suggested patch?)
1956 all file opens fail if... (fixed in SVN revision 1323?)
1959 opening lots of files fails (because SFT not in 1 block?)
I suggest to release 2038 when 3 of those 6 bugs are fixed :-)
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
