Re: [Freedos-kernel] patch for the rename function, please check
Hi Eric, 2007/9/19 Eric Auer : > 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