I am trying to FTP some apple DMG files, if we do it by hand through Safari or IE it ends up at the destination just fine and uncorrupted. However, if I use a freeware FTP client that we had been using with great success for zip's and exe's or if I use a Powershell script I finished off (adapted from another stackover flow's question's answer) then I lose about a 1/2 Mb on a 10.5 Mb file and the dmg is corrupted. Does anyone have anyclues what could be going wrong? Things I could do to prevent it? So far all I have tried is gzipping the dmg before sending and that accomplished nothing. Again, anything but a dmg gets transmitted just fine.
FYI I am using binary mode transfers, so that is not it..thx though
Seems like your client treats dmg file as text file.
set Binary transfer mode in your ftp client and it will ftp it as is.
I always thought that ascii transfer mode in ftp is just plain stupid. It causes more trouble then it is worth.
Are you sure everything except a DMG gets transferred correctly? It sounds like a problem with the transfer encoding. FTP supports both binary and ASCII transfer types, mainly due to historical baggage. In ye old days, when bandwidth was scarer, leaving off the high bit (which ASCII doesn't use) was a good time saver. However, if you have any bytes with the bit set, ASCII transfer mode will lose them - hence "binary" mode, which truncates nothing.
Typically, the command to switch transfer modes is "bin" or "ascii".
Just so everyone knows. It must have been the client I was using had the exact same issue as my PowerShell script. I was using StreamReader to get the bytes for transfer and it was assuming an encoding which was not correct. I switched to a BinaryReader which does not, and it now works.
Related
I’ll set my outrage with the way this process works (to whom can I speak?) aside for the moment: we are attempting to provide FB with a link to our ~200 mb app for approval. We have been rejected 3 times because they are incapable of extracting our zip file (they request a zip for some unknown reason — it has minimal size impact).
Some detail: we are linking to the zip on our Dropbox. We have removed all punctuation from our app title (Pandamonium!.app becomes Pandamonium.app). We have eliminated spaces from our source folder. I thought all these could be causing a problem with iOS-sim.
I’m not sure what is left to do, but I am hoping someone can present a clear set of instructions (NOT THEIR INSTRUCTIONS, WHICH I HAVE READ) they have followed particularly if you have met similar snags or ANY ideas for resolution. All they send me is useless screenshots of their simulator unable to open the app which I have simulated and opened successfully daily with iOS-sim for the last week.
After a great deal of trial and error I found that using Facebook's command-line instructions was what was causing the issue. You should just compress your .app file in an ordinary fashion (right click and compress -- I used a Windows computer just to make sure everything was copasetic after reading about bizarre Mac .cbgz compression issues).
Regardless, in summary, I can now see why no one else has had an issue with this: it's because no one reads their instructions and rather just creates their .zip files in the ordinary way; unsurprisingly, you're better off using your common sense rather than listening to others.
Aside: ironically, after being told my use case was fine and the only issue was not being able to unzip, Facebook (India) has now told me they couldn't find my login button (which is gigantic, in multiple places, and clearly described in my instructions). This process is an absolute joke. I wish anyone going through this hell good luck.
The thing that I am trying to do is I need to constantly check if a file on a shared corporate network location is available. The network admin performs a copy command and copies a large disk image file .iso to this target network location. The upload (copy) process takes about 4-5 hours, and in order to copy this file to my local computer, I need a way to determine whether this file has been fully copied or not.
I have tried using System.IO.fileinfo::Open, and it worked on my local experiment.
But yesterday when it checks, it failed to tell if the file is locked--the file is not constantly locked, and since it takes 5 hours, it seems that occasionally the file becomes unlocked briefly (possibly due to OS's trying to allocate another continuous space for that file). Hence my powershell script failed.
I also tried checking the size of the file as it is being copied over, but apparently the size of the file is constantly its original size, so this would not work.
So does anyone have any ideas how can this be verified? Thank you in advance.
There is a FileSystemWatcher but I am not sure if it works reliably on network folder. Another option is try check last write time of the file, and if the last write time is not changed for, say, 3 minutes, chances are that the copy is finished. You can also combine this with your lock check.
I have a PNG file created using libPNG library. The file opens perfectly on Windows picture viewer and MS Paint, but opening with kview (on Linux RHEL5) or QuickTime PictureViewer (on Windows) fails - the former reports a "libpng read error whereas the latter reports the file as being corrupted. A similar problem is seen when trying to process the PNG using ImageMagick library on Linux. Given that the PNG opens fine on some applications, it doesn't seem that the file is really corrupted; I therefore suspect some problem with version compatibility, but I am not sure. I tried searching the web but couldn't find any information on the root cause or a solution to this problem. Can someone please guide me on this?
Judging from the example image you posted in the comments, the problem is that your PNG lacks the ending IEND chunk -something you can test by opening it with tweakpng and inspecting the structure visually, or choosing "Check Validity-F5". It is somewhat predictable that those kind of PNG are displayed by some viewers and rejected by others.
If you are using libpng, it seems you forgot to call png_write_end()
I have a bunch of unicode (UTF-16LE) xml files that I want to transfer via an old OLD vb6 ftp component, but when I send them through there, they turn to ANSI on the ftp server side (win2k3 server).
When I attempt to send it using the windows terminal ftp client, it works fine whether I use binary or ascii transfer mode. The file stays unicode. What could be possible causes of this?
Edit: perhaps unrelated, but I notice sending files through an old email component also does this to unicode files.
The answer was finalized here; Writing ANSI string to Unicode file over FTP
Whenever I alter (or even just resave without altering) a Perl file, it completely takes down our backend. I have no idea what the problem could be. Permissions are correct. Encoding is correct. Encoding is UTF-8. Transfer mode was ASCII.
I might not deal with Perl too much but I have no idea what the problem could be. The network admin hosting our website has no idea what the problem could be.
Text editors I tried: Dreamweaver, TextMate, Vim
Operating systems I tried: Mac OS X, Linux (Ubuntu)
FTP clients I tried: Transmit (Mac), Filezilla (Linux (Ubuntu))
It's not that it's bad code, I even tried to open and solely save and my backend still goes down.
The network admin told me that he ran the files through a dos2unix converter and it worked immediately. I of course tried this and it did not, more so it wouldn't make any sense, since I tried this in some of the most respected editors and I don't think it would make such drastic changes to the file type without any user input. (when I say respected editors Dreamweaver is not included in that sentiment).
I personally think it is some sort of server-side issue because I have crossed my t's and dotted my i's in regards to any possible client side issue but I have tried everything. Any opinions as to what the root of this problem is, and any possible solutions? Thanks in advance.
Try setting binary mode in your FTP client. That will allow you to experiment with different line endings (dos2unix) on the client side, without worrying about them being translated during transfer.
I've had this problem in the past and line-feeds were indeed the culprit.
Your editor and/or FTP program may be mangling the linefeeds.
Running dos2unix on the server is a good test as to the problem but not the cause.
Generate an MD5 hash of the file after each step in saving and transport to find where it changes.
You do not say what kind of framework/server you are using.
Maybe the server reloads the file while it is still being written by FTP or whatever? (I.e. that the file is not complete when the server reads it?)
Will a server restart fix the problem once the file is uploaded?
It sounds like you are using dos2unix before the transfer but the network admin is using it after. Perhaps it's doing something different in that case.
How many lines are in the file? What is the file size before and after you save it, after you transfer it, and after transfer and running dos2unix on it?
If this is just a line ending problem, you might point your network admin at http://www.perlmonks.org/?node_id=586942.
Response to rebra: No frameworks are used, and I don't know what kind of server this is on. This is basically a one man project on a shared host which was pretty horribly maintained and I'm trying to clean house.
Yeah that does make sense and I asked the server people about that, one of my first questions actually, but even if that is the case, I can't reboot via Plesk (kind of like cPanel). But thanks for that, you put into technical words/explanation what I was thinking of the whole time.