Thread: Archiver
View Single Post
Old 10-10-2011, 08:55 PM  
Yil
Too much time...
 
Join Date: May 2005
Posts: 1,194
Default

Jeza: When you say the info about uploaded files is lost are you talking about the file/group/timestamp/perms of the files themselves or are you talking about the zipscript info such as ioNinja shows you when entering a directory?

The later is chattr data stored in the .ioFTPD file itself for the directory. If you create the target dir then immediately copy the .ioFTPD file into the dir like I suggested then this data probably makes it over. I say probably because without telling ioFTPD to mark the dir as stale and forcing it to re-read the .ioFTPD file it might not pick up the change and write out a blank entry with no chattr data in it if someone access the dir between creation and the copying of the .ioFTPD file. There's a number of other rare race conditions but that's the most likely because you're doing this all behind ioFTPD's back...

On the other hand, if you're talking about normal file perm stuff the problems go from really rare to annoyingly often. You're obviously aware that internally ioFTPD caches every directory before it's displayed/used by the server. That's necessary because that is when the permission information from the .ioFTPD file is applied to the directory itself and any files in the directory. To make sure the cache isn't stale because of external manipulation of the directory (i.e. files added/deleted in windows explorer, zipscripts extracting files, etc) the directory timestamp is compared against the cached entry and if they differ the cache is updated. Currently this means the directory is rescanned and the .ioFTPD reparsed, however if the .ioFTPD file notices that it has entries for non-existing files (and I think missing entries for files) it re-writes itself when done so it reflects the current directory.

What that actually means is problems. You see, if you move a file from the src dir to the dest dir and a user accesses the src dir again the .ioFTPD file gets re-written to reflect the deleted file. If you grabbed the .ioFTPD at the start, like I mentioned above, nothing about existing files is lost. The problem for you is much trickier at the dest dir though if you copied the .ioFTPD only at the start and someone enters the dest dir it will clear all the entries for the missing files. ioFTPD doesn't have this problem because it locks the dest and src dir so nobody can enter/touch them at all while things are being moved...

Now you see why I mentioned it would be really useful to just give you a ioFTPD copy dir function or expose dir locking facilities. But that would of only helped you if you were doing this in TCL, but in C# even the chattr get/set and vfs permission functions can't be used by you right now.

On the other hand you do have a 99% good enough solution I think. Grab the .ioFTPD file at the start, make a list of all files to copy by examining the dir, then make the dest dir, copy the .ioFTPD file into the target dir and make a backup of it there or just stash it in memory as it isn't large, then copy all the files from the list you made (you can deleted after each file), then re-write the destination .ioFTPD from the backup/memory copy at end. That should cover almost everything except permission changes while the copy is taking place and any new files added to the src/dest which in an archiver shouldn't really be happening... In TCL I'd suggest tricks like make the dest a hidden private dir, read-only, etc but just copying the .ioFTPD file at the start then re-writing the same info (not the current .ioFTPD file at src) at end should work for you.
Yil is offline   Reply With Quote