FlashFXP Forums - View Single Post

Yil · 05-11-2007, 02:48 AM

I "fixed" the rename issue when renaming a file that just differs in case of letters. However, when testing it I ran into several other issues I think need addressing.

1) When you rename a file/dir (even just by case) it will try to move the file to the last filesystem listed in a merged/raided directory. I've already identified the place to add logic to attempt to preserve the filesystem a file is on to prevent this behavior. It's a bit trickier since moving a directory across mountpoints or something should try to keep the files local as well and that's more of a move than a rename...

2) I specifically disallow renaming of mount points. Whatever is listed in the VFS is how you should see things. You can still move/rename the target of a mountpoint if it's visible somewhere else in the VFS which will break the association if you do it, but I think that's OK.

3) The code to determine which filesystem to move a file to in #1 is probably the place to add logic to test for free space issues I've added to the wishlist. Why try to move a directory to a filesystem that doesn't have room for it when another raided one does? Right now it will test for the space before the move, but not proceed to the next filesystem and test again.

To really fix the problem the correct place to make some changes looks to be in the path resolver and changing that might have issues... Therefore I'm going to not release a quick fix for this and try to solve it right later on in a 6.2 release.

P.S. The test for a stale cache entry is case insensitive and renaming a file doesn't update the file's timestamp. Therefore my suggestion of using a script to do the rename won't work. You'll need to rename test to testA to Test to force the update which sucks on non-leaf directories since the odds of someone else being in it go up which will prevent the rename from working...

05-11-2007, 02:48 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	Rename issue update I "fixed" the rename issue when renaming a file that just differs in case of letters. However, when testing it I ran into several other issues I think need addressing. 1) When you rename a file/dir (even just by case) it will try to move the file to the last filesystem listed in a merged/raided directory. I've already identified the place to add logic to attempt to preserve the filesystem a file is on to prevent this behavior. It's a bit trickier since moving a directory across mountpoints or something should try to keep the files local as well and that's more of a move than a rename... 2) I specifically disallow renaming of mount points. Whatever is listed in the VFS is how you should see things. You can still move/rename the target of a mountpoint if it's visible somewhere else in the VFS which will break the association if you do it, but I think that's OK. 3) The code to determine which filesystem to move a file to in #1 is probably the place to add logic to test for free space issues I've added to the wishlist. Why try to move a directory to a filesystem that doesn't have room for it when another raided one does? Right now it will test for the space before the move, but not proceed to the next filesystem and test again. To really fix the problem the correct place to make some changes looks to be in the path resolver and changing that might have issues... Therefore I'm going to not release a quick fix for this and try to solve it right later on in a 6.2 release. P.S. The test for a stale cache entry is case insensitive and renaming a file doesn't update the file's timestamp. Therefore my suggestion of using a script to do the rename won't work. You'll need to rename test to testA to Test to force the update which sucks on non-leaf directories since the odds of someone else being in it go up which will prevent the rename from working...