-
-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add zip to archives in File Manager #2163
Conversation
8a5943c
to
44ceea6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks okay for now other than the repeated definition of $externalPrograms{unzip}
.
Eventually we should eliminate $externalPrograms{tar}
and $externalPrograms{unzip}
and use Perl modules for the things they are used for (we already use the zip module and there is a good module for tar as well I believe). That would be more portable, and not have all of the possible issues with versions of these programs installed on systems that are not compatible. This should be done with many of the other $externalPrograms
as well (like mv
, cp
, rm
, and mkdir
which all can be handled with either built in Perl or a module).
By the way, I realize this is a draft, but the note on replacing |
Should we roll that into this PR or (probably) make a separate one? If a separate one, we should replace |
If you want to do that. This is okay for now though if you want to put it off. |
44ceea6
to
efd7a8e
Compare
Updated this and now has the ability to make either zip or tgz archives. Also, removed the use of A few issues:
|
The message that is reported when an archive is created is not on line 403 (nor 404 now). That message would be on line 378, and that maketext call has invalid maketext syntax for the quant. It is incorrect in develop and main (and has been since 2016). The syntax does not allow for spaces after commas. So |
Yeah, that isn't going to work. That looks particularly bad. I am not even sure that css styling can fix it. It is probably going to have to go somewhere else. Or most likely this is going to need to be reworked entirely to have the "Make Archive" button open a new page on which the user selects the type of archive. In my opinion this is needed anyway, rather than just blindly creating an archive file. The user should also have the option to select the archive file name, and a report should tell the user what files are going to be added to the archive. |
Also, you added the usage of the |
Oops. I was looking at |
We might be able to do this in a bootstrap dialog--otherwise I can create a new page. |
The FileManager.pm module has a mechanism for separate pages. It uses it for confirmations, file deletion, file view and edit, and the default view is the "refresh". So it is pretty easy to do this without creating a new module. |
efd7a8e
to
7a79b63
Compare
This adds Archive::Extract to check_modules.pl and libarchive-extract-perl to docker files. In addition, the UI now has a secondary page for creating an archive. |
7a79b63
to
925037a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some serious problems with this pull request. The chdir
issue is the biggest. The fact that archives can't actually be made at all with the new page is pretty big too though.
templates/ContentGenerator/Instructor/FileManager/archive.html.ep
Outdated
Show resolved
Hide resolved
templates/ContentGenerator/Instructor/FileManager/archive.html.ep
Outdated
Show resolved
Hide resolved
templates/ContentGenerator/Instructor/FileManager/archive.html.ep
Outdated
Show resolved
Hide resolved
There are some other problems with this as well. This does not deal with symlinks or directories correctly. Your code follows symlinks treating them as directories instead. The glob that you use for directories also does not recurse into subdirectories. |
Working on this now. I think I can use |
I have a pull request to your branch coming soon that fixes all of the issues I listed. So you might want to wait for that instead of working on it yourself. |
Fix the action. There needs to be a hidden "confirm" input. Improve layouts. Also other clean up suggested in my review of openwebwork#2163. Don't use `chdir`. The IO::Compression::Zip module is too limited. It can not add directories to the zip file. Empty directories in particular should be. So use Archive::Zip instead. This module is already in use by webwork as well.
I added a pull request to this branch with what I have for now. There is one issue left unresolved though. That is symbolic links in zip files. That should work, but there is a permissions error when attempting to add them. I don't know why yet. |
Fix the action. There needs to be a hidden "confirm" input. Improve layouts. Also other clean up suggested in my review of openwebwork#2163. Don't use `chdir`. The IO::Compression::Zip module is too limited. It can not add directories to the zip file. Empty directories in particular should be. So use Archive::Zip instead. This module is already in use by webwork as well.
Fix the action. There needs to be a hidden "confirm" input. Improve layouts. Also other clean up suggested in my review of openwebwork#2163. Don't use `chdir`. The IO::Compression::Zip module is too limited. It can not add directories to the zip file. Empty directories in particular should be. So use Archive::Zip instead. This module is already in use by webwork as well.
Fix the action. There needs to be a hidden "confirm" input. Improve layouts. Also other clean up suggested in my review of openwebwork#2163. Don't use `chdir`. The IO::Compression::Zip module is too limited. It can not add directories to the zip file. Empty directories in particular should be. So use Archive::Zip instead. This module is already in use by webwork as well.
Should we include symlinked files in the archives? Right now I have a working version using |
Yes, not only is the |
What version of zip are you testing? Or maybe I can't make a .zip to test correctly.
But when I try to extract it, it won't extract things into
so the version of unzip I'm using in bookworm (6.0-28) seems to already remove I think @drgrice1 suggestion of parsing the list and only extracting the valid files is best in the long run. |
We were testing this with the |
Ahh, I incorrectly assumed |
Parsing ahead of time would be nice because you could identify which files you might be overwriting and report that to the user. |
The `Archive::Extract` module is not safe with zip files and can extract files outside of the current working directory (assuming the server has write permission to do so). The `Archive::Zip` and `Archive::Tar` modules will not extract outside of the current working directory (by default). Additionally, using the `Archive::Zip` and `Archive::Tar` modules gives more power for archive extraction. If the "Overwrite existing files silenetly" checkbox is not checked, then this now checks each file in the archive to see if extracting it will overwrite an existing file. If so it refuses to do so, and a message is displayed.
@pstaabp: I added yet another pull request to this branch that fixes the issue with extracting archives with |
Switch to using `Archive::Zip` and `Archive::Tar` to extract archives.
Merged @drgrice1 PR and also updated the error handling. Instead of listing every existing file, it lists the number and the first filename or two. I had an example with 30+ existing files and the previous version listed every one. |
I don't really think you should have done that. This is an edge case that really should never happen. Archive files should never be created that do this sort of thing. If you are creating an archive that you are going to share with someone else in particular, this is considered extremely bad practice. If you have an archive that does this the message should show it all. Furthermore, you did this for zip archives, but you didn't do it for tar archives. Very inconsistent behavior. If you extract an improperly made tar archive that has files that would be extracted outside of the working directory, you still will get each file listed. Note that for tar archives this is handled by the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This now needs more work. All files need to be shown. Not a summary potentially showing at most 2. Those can be combined into a single alert, but none of them can be omitted. Perhaps in the extreme of a very large number this can be done, but showing only 1 or 2 does not give the user enough information.
my (@members, @existing_files); | ||
my $num_extracted = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The @members
variable defined here is never used. You still have my @members
in both of the if .. elsif
below that shadows this variable.
$c->addbadmessage($c->maketext( | ||
'There are [_1] files that already exist including [_2] and [_3]. ' | ||
. 'Check "Overwrite existing files silently" to unpack these files', | ||
scalar(@outside_files), | ||
$outside_files[0], | ||
$outside_files[1] | ||
)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very bad idea. The user needs to know ALL files that would be overwritten to make the determination to check the "Overwrite ..." checkbox. This is not thought out.
$c->addbadmessage($c->maketext( | ||
'There are [_1] files that already exist including [_2] and [_3]. ' | ||
. 'Check "Overwrite existing files silently" to unpack these files', | ||
scalar(@outside_files), | ||
$outside_files[0], | ||
$outside_files[1] | ||
)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't even the right message. These are files that would be extracted outside the working directory, and the message says these files exist.
@pstaabp: And another pull request to this one. This pull request makes it so that the first thirty files are listed for both files outside the working directory or already existing, and if there are more than that a note is made to that effect. |
Furthermore, each of those lists are in a single alert. |
This makes it so that the first thirty files in both lists are shown. If there are more than thirty, then the last item in the list will say that there are more files not shown. To make this work a `min` method was added to Utils.pm (there was a max method, but no min method?), and the change in openwebwork#2194 to make good and bad messages be in a `div` instead of a `p` was added here too.
Fix messages for existing files or files outside the course directory.
Looks good. Merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I think this is good again, and ready for another round of testing by someone else.
Finally getting around to test this. I have only been partially following the discussion here, so I may have missed somethings already discussed. My initial observations (I didn't test it in a way to try to break things with malformed archives). I only think the first one needs to be addressed. The others are just my thoughts when using the interface. When you select a single directory the file name is just directory name (Without When creating archive files in sub-directories, the archive is placed in the current working directory. This is reasonable, but it also starts to scatter archives around if people archive sub-directories. Would placing all archives in a single location like an When unpacking archives, they are unpacked into the current directory. Would adding an option to unpack them to some other directory and a confirm page be useful? I also didn't realize (until I got an error) that You can make archives of archives, and if someone starts to put archives in various sub directories, they may accidentally create archives of archives. Would it be reasonable to exclude archives from archives? Or have an option to exclude them checked by default? The archive page could also just not select archives by default, but list them, and maybe give the user a message that archives were found and are not selected by default. Similar issue would happen with the When no files are selected the |
One more thing, since the directory name doesn't append I guess this makes it more reasonable to add |
The
This is not feasible or even really realistic. The current working directory approach is the most reasonable way to do this. Placing the file in an
Unpacking to the current working directory is good enough for now. It is the way it currently works, and is all that is really needed at this point. You can add this as a feature request for future development if you like. A note on where archives are extracted could be added to the help. Using
Archives can be excluded by un-selecting them on the make archive page. Note that the previous behavior was to blindly add all files in sub-directories.
The current design makes more sense and is consistent with how the other buttons work on the page. You can quite easily select all files in the current working directory if you want all files in the archive. The point of the second page is to allow you to see what you have selected (including all files in subdirectories) and allow you to remove files (particularly from subdirectories) you don't want in the archive. I don't see your confusion on the greying out to be frank. |
@pstaabp: I added another pull request that makes sure the |
@somiaj: I want to clarify that I think some of the things you suggest are reasonable, but I think they are more aggressive than is needed for this pull request. This pull request started merely to add the feature of zip archive extraction and creation. I asked @pstaabp to add the new archive sub page to what he had initially, and since then several other things were requested. I think that this pull request has gone far enough, and needs to be merged. We can then add other features and such. I already have some other changes, and am tired of making pull requests to this one. |
I think an issue with this would be that if I'm in one working directory and make a generic I will try to test this later today or tomorrow. |
Add the .zip extension when a single file or directory without extension is selected.
This adds the ability to use zip/unzip for archiving/unarchiving in the File Manager.
Those on both Mac and PCs have zip/unzip ability more than a tar.gz file, so will increase the access to do handle archives.
This currently has the ability to unarchive zip files in the File Manager, but not yet archive them. I've been wondering about the UI to do this. Some of my thoughts are