add receive feature #74

brualan · 2018-08-08T10:46:34Z

More info: #58

claudiodangelis

If you agree, please address issues below. After that I have more comments about how the code is structured, but some issues need to be addressed first. Thanks!

claudiodangelis · 2018-08-08T10:49:03Z

main.go

@@ -17,37 +17,45 @@ var forceFlag = flag.Bool("force", false, "ignore saved configuration")
 var debugFlag = flag.Bool("debug", false, "increase verbosity")
 var quietFlag = flag.Bool("quiet", false, "ignores non critical output")
 var portFlag = flag.Int("port", 0, "port to bind the server to")
+var receiveMode = flag.Bool("recieve", false, "allows to receive files")


please replace with receiveFlag, for consistency

please fix typo recieve -> receive

please reword the description to "receives files"

claudiodangelis · 2018-08-08T11:02:27Z

main.go

+		}
+		serveFilesHTTP(generatedAddress, route, content, wg, stopSignal)
+
+		defer func() {


I'm not 100% sure why this function call should be deferred. Any hint?

Previously, if the program argument was a directory, the directory was compressed. In order to avoid unnecessary computation, the getContent() call is performed only when the program is supposed to serve files. But at the same time, the content should be deleted under certain conditions and not earlier than the server will finish its work. Because of this, the deletion must be done last. For such purposes, defer is used.

claudiodangelis · 2018-08-08T11:03:49Z

serveHTTP.go

+					}
+				}
+				// create output file if error was handled succesfully
+				out, _ = os.Create(filepath.Join(dirToStore, fileHeader.Filename))


Please check error here

claudiodangelis · 2018-08-08T11:10:38Z

serveHTTP.go

+							stop <- true // send signal to server to shutdown
+						}
+						// create output file if error was handled succesfully
+						out, _ = os.Create(filepath.Join(dirToStore, fileHeader.Filename))


Check error here as well

All errors handled above. At this point there will be no error

claudiodangelis · 2018-08-08T11:14:58Z

serveHTTP.go

+
+				// try to create output file
+				out, err := os.Create(filepath.Join(dirToStore, fileHeader.Filename))
+				defer out.Close()


Move defer out.Close() after checking the error

claudiodangelis · 2018-08-08T11:17:25Z

serveHTTP.go

+				// try to create output file
+				out, err := os.Create(filepath.Join(dirToStore, fileHeader.Filename))
+				defer out.Close()
+				if err != nil {


For sake of readability, please complement the behavior here: if err == nil, then return/abort/cleanup or do something else.

claudiodangelis · 2018-08-08T11:18:50Z

serveHTTP.go

+				defer out.Close()
+				if err != nil {
+					if os.IsNotExist(err) {
+						err := os.MkdirAll(dirToStore, os.ModePerm)


This can be refactored:

if err := os.MkdirAll(.....); err != nil { // fmt.fprintf... unable to create specified dir.... }

Also, double check spelling please.

claudiodangelis · 2018-08-08T11:20:02Z

serveHTTP.go

+				out, _ = os.Create(filepath.Join(dirToStore, fileHeader.Filename))
+
+				// write the content from POSTed file to the out
+				_, err = io.Copy(out, file)


This can be simplified:

if _, err := io.Copy(out, file); err != nil { // unable to write file to disk.... }

claudiodangelis · 2018-08-08T11:20:40Z

serveHTTP.go

+					stop <- true // send signal to server to shutdown
+				}
+
+				fmt.Fprintf(w, "File uploaded successfully: %s\n", fileHeader.Filename) //ouput to server


This code is reached even if err != nil, resulting in confusing message

More info: rename variable name "receiveMode" to "receiveFlag" fix typo in flag's name change flag's description

claudiodangelis · 2018-08-08T16:16:47Z

Sorry I accidentally clicked on "approve changes" and I cannot undo the action for some reason :-/

brualan · 2018-08-08T16:56:22Z

@claudiodangelis What should the program do if the user uploads a file with a name that is already taken. Maybe change the name of a new file like this photo.jpg -> photo(1).jpg and notify a user about that. Or should be this done some other way?

claudiodangelis · 2018-08-08T16:58:34Z

Very good question. I like the suffix idea, I think that should be the behavior in case of already existing file. Il giorno mer 8 ago 2018 alle ore 18:56 Alexandr Bruyako < notifications@github.com> ha scritto:

…

@claudiodangelis <https://github.com/claudiodangelis> What should the program do if the user uploads a file with a name that is already taken. Maybe change the name of a new file like this photo.jpg -> photo(1).jpg and notify a user about that. Or should be this done some other way? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5fixMFkS4_GWVq9pATvYea3k6KEQYmks5uOxg6gaJpZM4Vzs1M> .

claudiodangelis · 2018-08-08T16:59:53Z

Maybe, once the transfer is complete, we just print the name of the downloaded file, either it existed or not. Il giorno mer 8 ago 2018 alle ore 18:58 Claudio d'Angelis < claudiodangelis@gmail.com> ha scritto:

…

Very good question. I like the suffix idea, I think that should be the behavior in case of already existing file. Il giorno mer 8 ago 2018 alle ore 18:56 Alexandr Bruyako < ***@***.***> ha scritto: > @claudiodangelis <https://github.com/claudiodangelis> What should the > program do if the user uploads a file with a name that is already taken. > Maybe change the name of a new file like this photo.jpg -> photo(1).jpg > and notify a user about that. Or should be this done some other way? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#74 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA5fixMFkS4_GWVq9pATvYea3k6KEQYmks5uOxg6gaJpZM4Vzs1M> > . >

brualan · 2018-08-08T17:13:47Z

@claudiodangelis I see it like that: if the user uploads a file with a name that is already taken filename changes to original_file_name + (number) and when transfer complete we print File [original_file_name + (number)] was successfully upload

claudiodangelis · 2018-08-08T17:17:57Z

I see it similarly: we define a "filename" variable set to the uploading file. If the uploading filename already exists, we change the variable name by adding a suffix. At the end of the process, we print the filename variable which may or may not have been edited since the initial definition.

claudiodangelis · 2018-08-08T17:18:26Z

I'm leaving my desk now, please expect delayed responses. 🌚

brualan · 2018-08-10T22:43:01Z

@claudiodangelis Have you seen last changes?

claudiodangelis · 2018-08-13T08:57:59Z

Yep, it works great, many thanks for this. I think there is still room for improvement though, please allow me some time to do a second review.

claudiodangelis · 2018-08-13T09:00:57Z

For example, what about renaming the flag to -receive-to?

As of now what happens is extremely confusing because there is no indication to the user of what the first argument will be used for if the -receive flag is used, and if no arg is passed the program quits with a generic "at least one argument is required".

brualan · 2018-08-13T15:51:30Z

@claudiodangelis In the majority of programs, the flags reflect not the specific behavior of the program, but the concept of what it will do (extract, help, recursive, and so on). Perhaps for consistency it's worth to leave just receive?

claudiodangelis · 2018-08-13T15:57:14Z

Yes, completely agree with you, receive-to does not sound good at all. Let's stick to receive, and add an optional -dir (or -out, or please suggest). If -dir/-out is not passed, transfered file is stored into the current working directory, otherwise will use -dir/-out.

Additional args should be ignored, for example in the case of:

qr-filetransfer -receive /path/to/something

the file should be transfered to the current working directory, not to /path/to/something.

What do you think?

brualan · 2018-08-13T16:09:48Z

I do not really like the idea of defining a directory as a separate flag. It is better to leave the current version, when the destination directory is specified after the receive flag. And in the case when the user does not specify a directory, displays the message At least one argument is required. In case you want to save the file in the working directory, you can simply call the program like this qr-filetransfer -receive .

claudiodangelis · 2018-08-13T17:06:42Z

Ok, I'm not 100% convinced but let's try this way. Does it currently handle both absolute and relative paths? Il lun 13 ago 2018, 18:09 Alexandr Bruyako <notifications@github.com> ha scritto:

…

I do not really like the idea of defining a directory as a separate flag. It is better to leave the current version, when the destination directory is specified after the flag. And in the case when the user does not specify a directory, displays the message At least one argument is required. In case you want to save the file in the working directory, you can simply call the program like this qr-filetransfer -receive . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5fi7jBwZprOD34ymFtUPphBkJ92ugUks5uQaTMgaJpZM4Vzs1M> .

brualan · 2018-08-13T17:41:57Z

Yes, both relative and absolute. Tested only on Linux, but I think there will not be problems on other operating systems, because only standard library functions were used and none of "system-specific hacks"

claudiodangelis · 2018-08-14T07:58:43Z

Meanwhile the project got a logo (arasatasaygin/openlogos#4), I'm awaiting logo's assets so we can include it in the upload page.

claudiodangelis · 2018-08-14T15:37:34Z

I will improve the html tomorrow, include the logo and merge to master 💪

claudiodangelis · 2018-08-16T07:27:52Z

Merged, thank you @brualan!

brualan · 2018-08-16T14:53:04Z

@claudiodangelis Awesome! Can you please update README, to let people know how to use this feature?

add receive feature

6d6c7fe

claudiodangelis requested changes Aug 8, 2018

View reviewed changes

fix receive flag

e7cbb3d

More info: rename variable name "receiveMode" to "receiveFlag" fix typo in flag's name change flag's description

claudiodangelis approved these changes Aug 8, 2018

View reviewed changes

fix issues in the logic of receiving files

0a9d144

claudiodangelis merged commit a872254 into claudiodangelis:master Aug 16, 2018

claudiodangelis mentioned this pull request Aug 16, 2018

Add upload capability #8

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add receive feature #74

add receive feature #74

brualan commented Aug 8, 2018

claudiodangelis left a comment

claudiodangelis Aug 8, 2018

claudiodangelis Aug 8, 2018

brualan Aug 8, 2018

claudiodangelis Aug 8, 2018

claudiodangelis Aug 8, 2018

brualan Aug 8, 2018

claudiodangelis Aug 8, 2018

claudiodangelis Aug 8, 2018

claudiodangelis Aug 8, 2018

claudiodangelis Aug 8, 2018

claudiodangelis Aug 8, 2018

claudiodangelis commented Aug 8, 2018

brualan commented Aug 8, 2018

claudiodangelis commented Aug 8, 2018 via email

claudiodangelis commented Aug 8, 2018 via email

brualan commented Aug 8, 2018

claudiodangelis commented Aug 8, 2018

claudiodangelis commented Aug 8, 2018

brualan commented Aug 10, 2018

claudiodangelis commented Aug 13, 2018

claudiodangelis commented Aug 13, 2018

brualan commented Aug 13, 2018

claudiodangelis commented Aug 13, 2018

brualan commented Aug 13, 2018 •

edited

Loading

claudiodangelis commented Aug 13, 2018 via email

brualan commented Aug 13, 2018

claudiodangelis commented Aug 14, 2018

claudiodangelis commented Aug 14, 2018

claudiodangelis commented Aug 16, 2018

brualan commented Aug 16, 2018

add receive feature #74

add receive feature #74

Conversation

brualan commented Aug 8, 2018

claudiodangelis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

claudiodangelis commented Aug 8, 2018

brualan commented Aug 8, 2018

claudiodangelis commented Aug 8, 2018 via email

claudiodangelis commented Aug 8, 2018 via email

brualan commented Aug 8, 2018

claudiodangelis commented Aug 8, 2018

claudiodangelis commented Aug 8, 2018

brualan commented Aug 10, 2018

claudiodangelis commented Aug 13, 2018

claudiodangelis commented Aug 13, 2018

brualan commented Aug 13, 2018

claudiodangelis commented Aug 13, 2018

brualan commented Aug 13, 2018 • edited Loading

claudiodangelis commented Aug 13, 2018 via email

brualan commented Aug 13, 2018

claudiodangelis commented Aug 14, 2018

claudiodangelis commented Aug 14, 2018

claudiodangelis commented Aug 16, 2018

brualan commented Aug 16, 2018

brualan commented Aug 13, 2018 •

edited

Loading