Browse Prior Art Database

Method and System for Distributing Non-Modifiable Files Across Heterogeneous Environments

IP.com Disclosure Number: IPCOM000199644D
Publication Date: 2010-Sep-13
Document File: 5 page(s) / 65K

Publishing Venue

The IP.com Prior Art Database

Abstract

When teams are working in global environments using different operating system technology and employing generic channels to transfer files, it is not trivial to ensure that specific files are not modified by all team members. This publication describes a method and system for efficiently specifying files as being not modifiable within a tool, and ensuring that other instances of the same tool used by users in distributed environments will acknowledge the non-modifiable semantic irrespective of how the files are transferred to the destination.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 24% of the total text.

Page 1 of 5

Disclosed is a process for efficiently specifying files as being not modifiable within a tool, and ensuring that other instances of the same tool used by users in distributed environments acknowledge the non-modifiable semantic irrespective of how the files are transferred to a destination. When teams are working in global environments using different operating system technology and employing generic channels to transfer files, ensuring specific files are not modified by all team members is a non-trivial requirement. Embodiments of the disclosed process ensure file(s) fitting certain criteria are non- modifiable in instances of a tool across distributed, heterogeneous environments.

In many software tools, including an integrated development environment (IDE) as one embodiment, a concept of a file is used to describe a structure that can hold data. Files are often shared between parties and are often editable within an IDE. Eclipse™1 is one embodiment of an IDE.

There may be scenarios where an IDE can edit files with a stipulation there may be one or more specific file(s) matching a specific criteria that are not modifiable (for example, not editable) by the end user. These certain files may be shared between users where users do not use the same environment (such as operation system) or the files may have to be transferred between users using a basic transportation channel. However, in some situations, it is desirable that files that are not modifiable at the source are also not modifiable at the destination.

An obvious solution to determining whether a file is modifiable is to use a read-only property the file system to capture information. However, several reasons why a file system property cannot be used to solve the problem include use of methods of distributing files that may not support the transferring of the read-only file system property. For example, a .zip file does not store the read-only file system property and thus is not able to reproduce a non-modifiable file at the destination.

Usage of the file system read-only property may conflict with other services that utilize this property, for example, a pessimistic source control system. Under these services, a file system read-only property is used to identify files that are in a checked in state. A user may then check out a file, which removes the read-only property from the file and renders the file writeable to modify the file. However, source control usage of a read- only property to indicate the semantic conflicts with usage defined to determine whether the file is modifiable. Identification of services, and how the services use a read-only file system property must be understood in a generic manner to satisfy all conflicts, which is a non-trivial exercise due to the numerous permutations of services.

A file system read-only property is applied at an individual file level. This is an inefficient mechanism when a particular class of files should be identified as n...