You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by ji...@codehaus.org on 2004/10/08 16:43:53 UTC
[jira] Created: (MPARTIFACT-39) Make file upload more robust
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/MPARTIFACT-39
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MPARTIFACT-39
Summary: Make file upload more robust
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-artifact-plugin
Assignee:
Reporter: Mark Diggory
Created: Fri, 8 Oct 2004 10:43 AM
Updated: Fri, 8 Oct 2004 10:43 AM
Environment: All scp, sftp and ftp upload of files to Repositories
Description:
We would recommend that for upload of files to a repository that the following cases be handled to provide greater robustness.
1.) All uploads be to a "staging" area, this staging area could be the same directory or a temp directory and would upload the file with the file name extension of
Henk Penning comments:
> That would be great.
>
> I think, the best way for adding/replace stuff is
>
> -- write a 'temp'
> -- rename 'temp' to 'file'
>
> because a rename is truly atomic if 'temp' and 'file' are
> in the same file system.
>
> If you can implement the 'temp' for 'file' to be,
> for instance, '.tmp.file', I can easily teach the checkers
> to ignore '.tmp.*' files. I think rsync does something
> like that (even better .tmp.$$.file).
>
So the goals here are to verify that rsync handles ".tmp.$$.file" which will stop it from attempting to sync partial uploads. Henk can alter the md5 checking utilities at Apache to postpone checking .tmp files md5 signatures.
2.) All file permissions on uploaded files would best handled to be only writable by the individual user, not writable by group and readable by all. All directory permissions should be writable for user and group and readable by all. This forces the following implementation to be required.
Any file upload that attempts to overwrite a file should instead, move that file out of the way to a temporary location, upload to the new file using strategy (1) and then name it to the old file, once this is completed the old file can be removed. This provides a means be which file "ownership" can be determined and maintained. The problem this solves is the following, if files are "group writable" then any individual in the group can overwite the file altering its contents, historically we cannot tell who actually made the alteration. If there are concerns about the integrity of the artifact or its signature, it is unclear who was responsible for the alteration.
-Mark Diggory
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MPARTIFACT-39) Make file upload more robust
Posted by ji...@codehaus.org.
The following issue has been updated:
Updater: Brett Porter (mailto:brett@codehaus.org)
Date: Fri, 8 Oct 2004 7:38 PM
Changes:
Fix Version changed to 1.4.2
---------------------------------------------------------------------
For a full history of the issue, see:
http://jira.codehaus.org/browse/MPARTIFACT-39?page=history
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/MPARTIFACT-39
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MPARTIFACT-39
Summary: Make file upload more robust
Type: Improvement
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-artifact-plugin
Fix Fors:
1.4.2
Assignee: Brett Porter
Reporter: Mark Diggory
Created: Fri, 8 Oct 2004 10:43 AM
Updated: Fri, 8 Oct 2004 7:38 PM
Environment: All scp, sftp and ftp upload of files to Repositories
Description:
We would recommend that for upload of files to a repository that the following cases be handled to provide greater robustness.
1.) All uploads be to a "staging" area, this staging area could be the same directory or a temp directory and would upload the file with the file name extension of
Henk Penning comments:
> That would be great.
>
> I think, the best way for adding/replace stuff is
>
> -- write a 'temp'
> -- rename 'temp' to 'file'
>
> because a rename is truly atomic if 'temp' and 'file' are
> in the same file system.
>
> If you can implement the 'temp' for 'file' to be,
> for instance, '.tmp.file', I can easily teach the checkers
> to ignore '.tmp.*' files. I think rsync does something
> like that (even better .tmp.$$.file).
>
So the goals here are to verify that rsync handles ".tmp.$$.file" which will stop it from attempting to sync partial uploads. Henk can alter the md5 checking utilities at Apache to postpone checking .tmp files md5 signatures.
2.) All file permissions on uploaded files would best handled to be only writable by the individual user, not writable by group and readable by all. All directory permissions should be writable for user and group and readable by all. This forces the following implementation to be required.
Any file upload that attempts to overwrite a file should instead, move that file out of the way to a temporary location, upload to the new file using strategy (1) and then name it to the old file, once this is completed the old file can be removed. This provides a means be which file "ownership" can be determined and maintained. The problem this solves is the following, if files are "group writable" then any individual in the group can overwite the file altering its contents, historically we cannot tell who actually made the alteration. If there are concerns about the integrity of the artifact or its signature, it is unclear who was responsible for the alteration.
-Mark Diggory
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org