Newsgroup: it.comp.macintosh
Titolo: Trasferire file

Esiste una qualche applicazione, un sito, possibilmente free, per trasferire
via internet dei file fino a 1Gb ?
Qualcosa che non debba installare nulla, e sia semplice il download
per il cliente ?
Grazie !

 per il cliente ?
Attivare il server FTP su Leopard non dovrebbe essere così complesso.
-- 
"E' la mia opinione e io la condivido"

Otello ha scritto:

Ma non per il cliente / segretaria che deve tirare giù il file video da 
300 Mb
per il capo.
Credo esistano dei siti web in java che fanno il lavoro, il problema che 
quasi
tutti trovano il modo di farti pagare troppi soldi.

 tutti trovano il modo di farti pagare troppi soldi.
Le varie gigamail non funzionano??
Bye
-- 
psss.: Se vuoi scrivermi in privato,
togli Sir. e cita il messaggio ; ]
[iMac 20" Leo@2,66]

 per le dimensioni che hai in mente tu.
Drop Box free è solo 100Mb, è troppo poco.

 Drop Box free è solo 100Mb, è troppo poco.
Non è 2gb?
https://www.getdropbox.com/pricing
-- 
/Willy/ - *Contatti*: 
http://snipurl.com/contatti
* *Libralis* - 
http://libralis.dii.unisi.it/
* *FAQ* di /it-alt.comp.software.mozilla/: 
http://FAQmozilla.willygroup.org
* *Gratuiki* - Software Free: 
http://gratuiki.willygroup.org
* *La bufala delle scie chimiche* - 
http://sciechimicheinfo.blogspot.com/

 Drop Box free è solo 100Mb, è troppo poco.
Sono 2 Giga:
"Free accounts come with 2GB of storage (deleted files and revisions don't 
currently count against your quota). You can always check your quota via your 
account page. You can also upgrade your Dropbox for more space."


tutti trovano il modo di farti pagare troppi soldi.
Il problema e' che qualche fesso deve prima fare l'upload del file
affinche' la segretaria idiota possa poi farne il download.
Se chi fa l'upload ha una ADSL e il file e' grosso stiamo parlando di
ore per fare l'upload contro decine di minuti per scaricarlo.
Saluti.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 Saluti.
-------------------------------------------------------------------------------
Si, anche questo è messo nel conto, purtroppo.
I siti che ho visto io sono tutti a pagamento

I siti che ho visto io sono tutti a pagamento
In alternativa potresti usare un programma come Hamachi (adesso
acquisito da LogMeIn) che ti permetterebbe di creare una rete privata
e bypassare il problema della mancanza di IP pubblico, ma devi
installare software sulle macchine che vuoi collegare.


Freddy Krueger ha scritto:

Non solo, devo convincere la segrataria

 scaricare il costo sul tuo cliente.
anche servizi tipo dyndns "simulano" l'ip pubblico

 wrote:

Jumbo Mail di Libero?
-- 
Quando c'era lui i treni partivano in orario
Quando c'era lui ci deportavano in orario

 Esiste una qualche applicazione, un sito, possibilmente free, per  

c'e' podmailing: 
http://www.podmailing.com/
-- 
ciao, paolo

anche servizi tipo dyndns "simulano" l'ip pubblico
Non con fastweb.


 via internet dei file fino a 1Gb ?
Io ho trasferito più di 200Mb con skypè...
-- 
Per rispondere, togliere -NOSPAM- dall'indirizzo.

 Io ho trasferito più di 200Mb con skypè...
Mica male come idea effettivamente. Nel caso specifico forse non va
perché richiede di installare (Skype) e creare (un account Skype),
però per la normalità dei casi può andare bene.
Tornando al quesito, dovrebbero esserci servizi di hosting backup
gratuito, devo dare un occhio alle mie riviste, c'era giusto una prova
recente, 300MB come spazio gratuito non è un problema, ma mi sfugge se
c'è un limite alle dimensioni del singolo file.
Poi mi sembra che Virgilio permetta l'invio di mail con allegati fino
a 2 GB. Non sarà l'unico immagino. ciao

a 2 GB. Non sarà l'unico immagino. ciao
Il trasferimento di grossi files via EMAIL invece e' proprio una
pessima ideo: a causa della codifica gli allegati binari sono circa il
33% piu' pesanti dei files di partenza, senza contare che l'upload
puo' fallire o che il file puo' arrivare corrotto.
Poi indipendentemente da quanto grossi possono essere gli allegati con
virgilio, c'e' da vedere qual e' la dimensione massima permessa dalla
casella del destinatario.
Si puo' ovviare creando una casella anche per il destinatario, ma a
parte l'idea idiota di usare la posta per una cosa del genere, poi
bisogna anche insegnare alla segretaria come usare il tutto.
La soluzione migliore e' e rimane FTP visto che e' nato apposta per il
trasferimento dei files, adesso si tratta di vedere se e' piu' pratico
lasciare i files sul PC di "Back in 5 min", abilitare il servizio IP
pubblico dal pannello di controllo di fastweb o se e' meglio
installare un server FTP sul PC della segretaria e mandare i files
quando servono.
Le altre opzioni, a meno di non pagare un hosting che permetta
l'accesso ad un server FTP con qualche GB di spazio a poche decine di
ero l'anno, secondo me sono palliativi costosi.
Saluti.


 33% piu' pesanti dei files di partenza, 
Mi sembra strano, non ci sono MIME per dati di tipo raw?

 casella del destinatario.
Vedi sopra.


Mi sembra strano, non ci sono MIME per dati di tipo raw?
Un byte in un file binario puo assumere valori da 0 a 255, quando
mandi una email gli allegati li codifichi in ASCII usando valori da 0
a 127.
Avendo necessita' di usare un altro byte per rappresentare i valori da
128 a 255 i dati trasferiti crescono di dimensione.
Cosi' almeno e' sempre stato spiegato.


ho una Alica 7Mb, dall'altra parte penso ci sia una connessione fastweb.
Io ho avuto esperienze positive (120K al secondo) e negative (3K), non
e' una soluzione da scartare a priori, ma potendo installare software
tanto vale installare hamachi e poi fare accedere alla segretaria ad
un server FTP tramite l'IP virtuale di Hamachi...

Rimango scettico: a questo punto meglio comprare spazio su un server
FTP, almeno si possono mandare i files direttamente con uin client FTP
e fare resume in caso l'upload si interrompa.
Ad ogni modo dover fare l'upload su un server di terze parti,
indipendentemente da come lo si fa', puo' essere una discreta perdita
di tempo.


 128 a 255 i dati trasferiti crescono di dimensione.
Questo raddoppierebbe la dimensione di un allegato mime piuttosto che 
aumentarla di un terzo. E' più probabile (e sano) che vengano codificati 
a gruppi contigui di 7 bit, come la maledetta codifica PDU per gli sms.

a gruppi contigui di 7 bit, come la maledetta codifica PDU per gli sms.
Dovrei leggermi le RFC e sinceramente non ne ho voglia... :)



 5.2  Base64 Content-Transfer-Encoding
            The  Base64   Content-Transfer-Encoding   is   designed   to
            represent  arbitrary  sequences  of octets in a form that is
            not humanly readable.  The encoding and decoding  algorithms
            are simple, but the encoded data are consistently only about
            33 percent larger than the unencoded data.  This encoding is
            based on the one used in Privacy Enhanced Mail applications,
            as defined in RFC 1113.   The  base64  encoding  is  adapted
            from  RFC  1113, with one change:  base64 eliminates the "*"
            mechanism for embedded clear text.
            A 65-character subset of US-ASCII is used, enabling  6  bits
            to  be  represented per printable character. (The extra 65th
            character, "=", is used  to  signify  a  special  processing
            function.)
            NOTE:  This subset has the important  property  that  it  is
            represented   identically   in  all  versions  of  ISO  646,
            including US ASCII, and all characters  in  the  subset  are
            also  represented  identically  in  all  versions of EBCDIC.
            Other popular encodings, such as the encoding  used  by  the
            UUENCODE  utility  and the base85 encoding specified as part
            of Level 2 PostScript, do not share  these  properties,  and
            thus  do  not  fulfill the portability requirements a binary
            transport encoding for mail must meet.
            The encoding process represents 24-bit groups of input  bits
            as  output  strings of 4 encoded characters. Proceeding from
            left  to  right,  a  24-bit  input  group   is   formed   by
            concatenating  3  8-bit input groups. These 24 bits are then
            treated as 4 concatenated 6-bit groups,  each  of  which  is
            translated  into a single digit in the base64 alphabet. When
            encoding a bit stream  via  the  base64  encoding,  the  bit
            stream  must  be  presumed  to  be  ordered  with  the most-
            significant-bit first.  That is, the first bit in the stream
            will be the high-order bit in the first byte, and the eighth
            bit will be the low-order bit in the first byte, and so on.
            Each 6-bit group is used as an index into  an  array  of  64
            printable  characters. The character referenced by the index
            is placed in the output string. These characters, identified
            in  Table  1,  below,  are  selected so as to be universally
            representable,  and  the  set   excludes   characters   with
            particular  significance to SMTP (e.g., ".", "CR", "LF") and
            to the encapsulation boundaries  defined  in  this  document
            (e.g., "-").
                            Table 1: The Base64 Alphabet
               Value Encoding  Value  Encoding   Value  Encoding   Value
            Encoding
                   0 A            17 R            34 i            51 z
                   1 B            18 S            35 j            52 0
                   2 C            19 T            36 k            53 1
                   3 D            20 U            37 l            54 2
                   4 E            21 V            38 m            55 3
                   5 F            22 W            39 n            56 4
                   6 G            23 X            40 o            57 5
                   7 H            24 Y            41 p            58 6
                   8 I            25 Z            42 q            59 7
                   9 J            26 a            43 r            60 8
                  10 K            27 b            44 s            61 9
                  11 L            28 c            45 t            62 +
                  12 M            29 d            46 u            63 /
                  13 N            30 e            47 v
                  14 O            31 f            48 w         (pad) =
                  15 P            32 g            49 x
                  16 Q            33 h            50 y
            The output stream (encoded bytes)  must  be  represented  in
            lines  of  no more than 76 characters each.  All line breaks
            or other characters not found in Table 1 must be ignored  by
            decoding  software.   In  base64 data, characters other than
            those in  Table  1,  line  breaks,  and  other  white  space
            probably  indicate  a  transmission  error,  about  which  a
            warning  message  or  even  a  message  rejection  might  be
            appropriate under some circumstances.
            Special processing is performed if fewer than  24  bits  are
            available  at  the  end  of  the data being encoded.  A full
            encoding quantum is always completed at the end of  a  body.
            When  fewer  than  24  input  bits are available in an input
            group, zero bits  are  added  (on  the  right)  to  form  an
            integral number of 6-bit groups.  Output character positions
            which are not required to represent actual  input  data  are
            set  to  the  character  "=".   Since all base64 input is an
            integral number of octets,  only  the  following  cases  can
            arise:  (1)  the  final  quantum  of  encoding  input  is an
            integral multiple of  24  bits;  here,  the  final  unit  of
            encoded  output will be an integral multiple of 4 characters
            with no "=" padding, (2) the final quantum of encoding input
            is  exactly  8  bits; here, the final unit of encoded output
            will  be  two  characters  followed  by  two   "="   padding
            characters,  or  (3)  the final quantum of encoding input is
            exactly 16 bits; here, the final unit of encoded output will
            be three characters followed by one "=" padding character.
            Care must be taken to use the proper octets for line  breaks
            if base64 encoding is applied directly to text material that
            has not been converted to  canonical  form.  In  particular,
            text  line  breaks  should  be converted into CRLF sequences
            prior to base64 encoding. The important  thing  to  note  is
            that this may be done directly by the encoder rather than in
            a prior canonicalization step in some implementations.
            NOTE: There is no  need  to  worry  about  quoting  apparent
            encapsulation  boundaries  within  base64-encoded  parts  of
            multipart entities because no hyphen characters are used  in
            the base64 encoding.
-- 
Questa, signori miei, è porno-anarchia...