Having tested successfully how to xfer files between two puppy PC's by setting up a ftp server on one of the puppy PC's I wanted to test this between a puppy PC (with the ftp server) and a XP PC
I used a gui ftp program on the XP PC, called FileZilla.
Uploading a file from the XP PC to the Puppy ftp server was no problem and the file could be used.
Downloading a file from the puppy ftp server to the XP machine didn't work. The file had 0 bytes length and hence wasn't usable.
What can be the reason?
Oh yes I use anonymous on and full acces on the puppy ftp server
FTP file transfer, puppy --> XP
if you are running Puppy 2.x using unionfs (you have a save file or are running in ram), you may need to download the files in /initrd/pup_rw and /initrd/pup_ro2 instead of the same files in /root etc etc etc
or you can use dotpup packages like pureftp, which seems to work with the unionfs file system
or you can use dotpup packages like pureftp, which seems to work with the unionfs file system
-
Béèm
- Posts: 11763
- Joined: Wed 22 Nov 2006, 00:47
- Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win
I don't quite understand the advice, so I will clarify.
On the puppy laptop I use beta FTPD FTP server (muppy) in anonymous mode and full access (download and upload)
When the destop is puppy, I have no problems nor in uploading nor in downloading.
When the desktop is XP (using a gui ftp program FileZilla) I can upload to the puppy ftp server and the file is usable in puppy (the files are available in /root/ftp) f.e. a movie, a mp3, a text file.
When I download to the XP PC I see the file in the directory with the correct name and extension but the file has no contents and is 0 bytes.
I tried auto as well as binary transfer modes.
I can understand that the format of the file, once downloaded to XP is wrong and unusable, but not with a 0 bytes length.
Hence my question what goes wrong with the download to XP, while the upload is correct?
On the puppy laptop I use beta FTPD FTP server (muppy) in anonymous mode and full access (download and upload)
When the destop is puppy, I have no problems nor in uploading nor in downloading.
When the desktop is XP (using a gui ftp program FileZilla) I can upload to the puppy ftp server and the file is usable in puppy (the files are available in /root/ftp) f.e. a movie, a mp3, a text file.
When I download to the XP PC I see the file in the directory with the correct name and extension but the file has no contents and is 0 bytes.
I tried auto as well as binary transfer modes.
I can understand that the format of the file, once downloaded to XP is wrong and unusable, but not with a 0 bytes length.
Hence my question what goes wrong with the download to XP, while the upload is correct?
if you are running Puppy with a save file, or if you are running Puppy in ram, the file system is layered by the unionfs module
if you are trying to transfer a file that is, for example, somewhere in /root, you are trying to transfer a file from the unionfs file system
but some of the http and ftp file servers, depending how they were built, do not like the unionfs file system ... what usually happens, is that you may be able to see the file in the server, but it looks like a directory, or you might be able to download the file, but it will not download properly, and the file will be empty (zero bytes)
one workaround to the problem is to configure the server so that the files that the server serves, are directly accessed, and not to go through the unionfs file system
for example, the files in /root/ghttpd are also visible and available in /initrd/pup_rw/root/ghttpd and also in /initrd/pup_ro2/root/ghttpd ... these are different layers that make up the top layer of the unionfs file system
so if it won't work to download from /root/ghttpd/htdocs/myfile.zip it might work to set the server to serve files from /initrd/pup_rw/root/ghttpd/htdocs instead ... if you put a file called myfile.zip in /root/ghttpd/htdocs there should be a duplicate ghost file in /initrd/pup_rw/root/ghttpd/htdocs (actually, it is the real file ... pup_rw is the Puppy save file)
or you can install the Monkey web server or the PureFTP ftp server, they seem to work properly with unionfs
if you have a full normal install of Puppy to a partition, the file system is not using unionfs, and this workaround would not apply ... in that case, the files should transfer properly, if they are not transferring properly, i don't know why they are not
by the way, do not delete or modify or add files to pup_rw ... unionfs does not like it, and will stop working until you remount the file system (reboot)
if you are trying to transfer a file that is, for example, somewhere in /root, you are trying to transfer a file from the unionfs file system
but some of the http and ftp file servers, depending how they were built, do not like the unionfs file system ... what usually happens, is that you may be able to see the file in the server, but it looks like a directory, or you might be able to download the file, but it will not download properly, and the file will be empty (zero bytes)
one workaround to the problem is to configure the server so that the files that the server serves, are directly accessed, and not to go through the unionfs file system
for example, the files in /root/ghttpd are also visible and available in /initrd/pup_rw/root/ghttpd and also in /initrd/pup_ro2/root/ghttpd ... these are different layers that make up the top layer of the unionfs file system
so if it won't work to download from /root/ghttpd/htdocs/myfile.zip it might work to set the server to serve files from /initrd/pup_rw/root/ghttpd/htdocs instead ... if you put a file called myfile.zip in /root/ghttpd/htdocs there should be a duplicate ghost file in /initrd/pup_rw/root/ghttpd/htdocs (actually, it is the real file ... pup_rw is the Puppy save file)
or you can install the Monkey web server or the PureFTP ftp server, they seem to work properly with unionfs
if you have a full normal install of Puppy to a partition, the file system is not using unionfs, and this workaround would not apply ... in that case, the files should transfer properly, if they are not transferring properly, i don't know why they are not
by the way, do not delete or modify or add files to pup_rw ... unionfs does not like it, and will stop working until you remount the file system (reboot)
-
Béèm
- Posts: 11763
- Joined: Wed 22 Nov 2006, 00:47
- Location: Brussels IBM Thinkpad R40, 256MB, 20GB, WiFi ipw2100. Frugal Lin'N'Win
Thank you, I understand better now.
I still have some difficulties to capt the concept of the union fs and its consequences.
As I use Muppy004 and it's betaFTPD ftp server and don't see how to configure to change the default /root/ftp to another directory, I'll look around for Monkey or pureftp.
On the other side apparently working from Puppy to Puppy with betaFTPD ftp server gives no problems in upload nor download. So the problem may be linked to the fact that download problem only occurs when done to a XP PC.
Also, as an exercise, I'll try to find a ftpserver for XP to work the other way round.
I still have some difficulties to capt the concept of the union fs and its consequences.
As I use Muppy004 and it's betaFTPD ftp server and don't see how to configure to change the default /root/ftp to another directory, I'll look around for Monkey or pureftp.
On the other side apparently working from Puppy to Puppy with betaFTPD ftp server gives no problems in upload nor download. So the problem may be linked to the fact that download problem only occurs when done to a XP PC.
Also, as an exercise, I'll try to find a ftpserver for XP to work the other way round.
