access denied, moving files

[lemonstar]

hi,

this f* problem is getting on my nerves. iam not capable of transfering files located on one hdd to another hdd. my vfs settings are the following.

"../site/" /
"d:/movies/" /movies
"e:/archiv/" /archiv

[L] RNFR /movies/kickflipp
[L] 350 File exists, ready for destination name.
[L] RNTO /archiv/kickflipp
[L] 550 /archiv/kickflipp: Access is denied.

chmod is set to 777 at both directories on the two different hdds.

[tuff]

copy and paste this into a file of your choice, then config your ioftpd.ini for a command for it ;)

proc ioMOVERLS {} {
global args pwd path iomove
if {![info exists args]} {iputs "Usage: site moverls directoy /to/where"; return}
if {![string match "*/*" [lindex $args 0]]} {set name "$pwd[lindex $args 0]"} else {set name [lindex $args 0]}
set realdir [resolve pwd $name]
catch {set temp [client kill virtualpath "$name/*"]} temp
catch {file rename -force -- "[resolve pwd $pwd]/[lindex $args 0]" "[resolve pwd [lindex $args end]]/[lindex $args 0]"} error
if {$error != ""} {iputs "$error"}
}
ioMOVERLS

[DayCuts]

Simply put, RNFR/RNTO uses the same move method as an operating system does when its moving a file from one location on a drive to another location on the same drive. It doesnt actually move any data, just changes the file system index so that its virtual path is different. Moving from one drive to another actually involves writing/deleting of data on both disks, this is an entirely different function call in the operating system.

I am personally not aware of any windows ftpd that has been made able to do this through RNFR/RNTO raws (possible due to rfc standards).

[lemonstar]

copy and paste this into a file of your choice, then config your ioftpd.ini for a command for it ;)

proc ioMOVERLS {} {
global args pwd path iomove
if {![info exists args]} {iputs "Usage: site moverls directoy /to/where"; return}
if {![string match "*/*" [lindex $args 0]]} {set name "$pwd[lindex $args 0]"} else {set name [lindex $args 0]}
set realdir [resolve pwd $name]
catch {set temp [client kill virtualpath "$name/*"]} temp
catch {file rename -force -- "[resolve pwd $pwd]/[lindex $args 0]" "[resolve pwd [lindex $args end]]/[lindex $args 0]"} error
if {$error != ""} {iputs "$error"}
}
ioMOVERLS

well iam stocking here, do i have to create a esspecially file for example iomove.itcl and copy all this into it. and then create a command for it in ioftpd so iam able to execute this file?

#edit:

well it works as u wrote. is there another method possible? iam talking about the nice drop and move feature u normaly have

[BoNeZz]

i try this code on my ioftpd 7.5.7r + ioninja + nxtools but not works

error is:

(23:55:29) [1] site moverls TEST /MYFTP/TESTMOVE/
(23:55:29) [1] 200-error renaming "C:/MYFTP/ioMOVERLS": no such file or directory

and in ioftpd.ini i added:

moverls = TCL ..\scripts\ioMOVERLS.itcl MOVERLS

also i try with:

iomoverls = TCL ..\scripts\ioMOVERLS.itcl ioMOVERLS

(difference is in IOmoverls) but change nothing.

i hope that someone can help me

bye

[Yil]

First things first. The root directory (/) entry in your VFS is invalid for 2 reasons. No local paths should end in a "\" unless it's a drive letter (and that is discouraged, mount a dir on the drive not the drive itself). This is fixed automatically but should be generating a warning to the error.log file the first time the .vfs file is used. The second reason is you cannot use relative links in the .VFS file as of version 7.5.3 (see changelog) because it can confuse the directory caching logic. This should be generating an error message to error.log now, and in earlier releases it should have been a warning message for a long time now...

I'm pretty sure that will fix the problem, but here's some more info for the record...

ioFTPD is pretty smart about RNFR/RNTO. It fully resolves the paths to the source and destination and issues a rename if on the same drive, else it locks the source/destination directories internally and does a per-file/directory copy from one drive to the other...

ioFTPD in general returns the following 3 permission errors messages itself:

"Permission denied" - write protected, generic permission failure, etc
"Permission denied (directory mode)" - rwx, 777, etc
"Permission denied (config file)" - action denied by .ini VFS rule

The first thing to note is your error message: "Access is Denied". This is an error generated by windows itself. Assuming the above VFS changes didn't fix things, can you check the actual permissions on the target directory in windows? Can ioFTPD create dirs and upload files to the location you are trying to copy to?

The other thing to watch out for is permission differences when run as a service. If you are running this as a service, try as a regular user and see if the problem goes away. If it does you'll probably need to setup the service to run as a user instead of under the default Local Service account. This especially applies to network mounted drives as they are not accessible to the Local Service account by default.

I'm aware of several possible issues with moving dirs across filesystems.

1) An active upload in a directory being moved will prevent that file / directory tree from being completely moved. If you are moving a large directory tree I suggest closing the site, waiting for uploads to finish, moving the files, and then opening it again.

2) If you use NTFS mountpoints to mount drive E: on c:\drives\e or something like that the test for using rename verse move will probably fail. This can be fixed in a future release now that ioFTPD knows about NTFS junctions, but for the moment just use the actual path in the .vfs file.

3) ioFTPD doesn't expose any hidden/system dirs for security reasons. You can mount regular dirs UNDER a hidden dir so the whole tree is hidden, but not a hidden dir directly. Also, avoid using drive roots like e:\ where possible and use e:\site or e:\games or something instead... It's possible I haven't updated the move operation to ignore a hidden parent dirs for a move like I have for uploads, etc so let me know if that appears to be the case.

4) Moving a release to/from a merged directory is a bit tricky if the dir exists on multiple drives... This will be addressed in a future release.

[BoNeZz]

First things first. The root directory (/) entry in your VFS is invalid for 2 reasons. No local paths should end in a "\" unless it's a drive letter (and that is discouraged, mount a dir on the drive not the drive itself). This is fixed automatically but should be generating a warning to the error.log file the first time the .vfs file is used. The second reason is you cannot use relative links in the .VFS file as of version 7.5.3 (see changelog) because it can confuse the directory caching logic. This should be generating an error message to error.log now, and in earlier releases it should have been a warning message for a long time now...

I'm pretty sure that will fix the problem, but here's some more info for the record...

ioFTPD is pretty smart about RNFR/RNTO. It fully resolves the paths to the source and destination and issues a rename if on the same drive, else it locks the source/destination directories internally and does a per-file/directory copy from one drive to the other...

ioFTPD in general returns the following 3 permission errors messages itself:

"Permission denied" - write protected, generic permission failure, etc
"Permission denied (directory mode)" - rwx, 777, etc
"Permission denied (config file)" - action denied by .ini VFS rule

The first thing to note is your error message: "Access is Denied". This is an error generated by windows itself. Assuming the above VFS changes didn't fix things, can you check the actual permissions on the target directory in windows? Can ioFTPD create dirs and upload files to the location you are trying to copy to?

The other thing to watch out for is permission differences when run as a service. If you are running this as a service, try as a regular user and see if the problem goes away. If it does you'll probably need to setup the service to run as a user instead of under the default Local Service account. This especially applies to network mounted drives as they are not accessible to the Local Service account by default.

I'm aware of several possible issues with moving dirs across filesystems.

1) An active upload in a directory being moved will prevent that file / directory tree from being completely moved. If you are moving a large directory tree I suggest closing the site, waiting for uploads to finish, moving the files, and then opening it again.

2) If you use NTFS mountpoints to mount drive E: on c:\drives\e or something like that the test for using rename verse move will probably fail. This can be fixed in a future release now that ioFTPD knows about NTFS junctions, but for the moment just use the actual path in the .vfs file.

3) ioFTPD doesn't expose any hidden/system dirs for security reasons. You can mount regular dirs UNDER a hidden dir so the whole tree is hidden, but not a hidden dir directly. Also, avoid using drive roots like e:\ where possible and use e:\site or e:\games or something instead... It's possible I haven't updated the move operation to ignore a hidden parent dirs for a move like I have for uploads, etc so let me know if that appears to be the case.

4) Moving a release to/from a merged directory is a bit tricky if the dir exists on multiple drives... This will be addressed in a future release.

sorry i don't understand

my vfs at the moment is too simple:

"C:\ioFTPD\FTP-ROOT-DIR" /
"C:\MYFTP" /MYFTP

and with this code not work site moverls.

with ftp regular move is not possible move a dir with subdirs between device: (example: from C: to D: )

[Yil]

I can't speak for "site moverls" not working, but unless something recently broke (hey, it's possible!) you absolutely CAN move directories or entire directory trees between hard disks within the ftp just using RNFR/RNTO...