FlashFXP Forums - View Single Post

Yil · 02-16-2011, 05:07 AM

chico2: Haven't been in front of a computer for a while, so I hope you figured out a solution...

Check logs/error.log and see what it reports as the reason you can't login...

My guess is the etc/UserIdTable file got corrupted since you can't login to 2 different usernames. If that file has issues you may still have the individual userfiles in /users you don't have the file that maps user-ids to names so you can't login... I have seen this happen before, but it's very very rare. One possible cause is ioFTPD corrupting memory and destroying the in-memory database so when it's written out the info is wrong. The other might actually be a windows filesystem race condition if the server looses power at just the wrong time or something which is possible if things don't shutdown correctly...

For the record, whenever a user is added or renamed the etc/UserIdTable file is recreated by writing the contents of the file to UserIdTable.new, flushing the buffers, and then renaming the new file to the old one. I really don't see how that should be able to fail under NTFS but I'm not ruling it out, but it's far more likely that the way ioFTPD does it isn't exactly right or something. This is commonly the way to handle small file atomic updates and, as a side note, I remember Linux's ext4 had an issue where such operations were broken when it first went live but nobody noticed for a while since it's rare.

As a side note: On the big TO-DO list is an entry to add the option of using transacted operations for some file operations if you are using Vista+. While the UserIdTable and GroupIdTable go out of their way with ".new" and renames the actual user, group, and all .ioFTPD files just overwrite the existing file contents and flush the buffers which can certainly lead to corrupted files if the server looses power. With Vista+ it might make sense to use transacted operations for at least the user/groupfile updates and maybe even the .ioFTPD operations if it turns out the overhead isn't high. I haven't tested it, just noted that it would be a nice option to test/benchmark...

02-16-2011, 05:07 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	chico2: Haven't been in front of a computer for a while, so I hope you figured out a solution... Check logs/error.log and see what it reports as the reason you can't login... My guess is the etc/UserIdTable file got corrupted since you can't login to 2 different usernames. If that file has issues you may still have the individual userfiles in /users you don't have the file that maps user-ids to names so you can't login... I have seen this happen before, but it's very very rare. One possible cause is ioFTPD corrupting memory and destroying the in-memory database so when it's written out the info is wrong. The other might actually be a windows filesystem race condition if the server looses power at just the wrong time or something which is possible if things don't shutdown correctly... For the record, whenever a user is added or renamed the etc/UserIdTable file is recreated by writing the contents of the file to UserIdTable.new, flushing the buffers, and then renaming the new file to the old one. I really don't see how that should be able to fail under NTFS but I'm not ruling it out, but it's far more likely that the way ioFTPD does it isn't exactly right or something. This is commonly the way to handle small file atomic updates and, as a side note, I remember Linux's ext4 had an issue where such operations were broken when it first went live but nobody noticed for a while since it's rare. As a side note: On the big TO-DO list is an entry to add the option of using transacted operations for some file operations if you are using Vista+. While the UserIdTable and GroupIdTable go out of their way with ".new" and renames the actual user, group, and all .ioFTPD files just overwrite the existing file contents and flush the buffers which can certainly lead to corrupted files if the server looses power. With Vista+ it might make sense to use transacted operations for at least the user/groupfile updates and maybe even the .ioFTPD operations if it turns out the overhead isn't high. I haven't tested it, just noted that it would be a nice option to test/benchmark...