natgillin/translations-raw huggingface dataset:
For at opnå denne vekselvirkning mellem slutsystemerne findes der i standarden en række filprotokoller, hvorigennem de nødvendige operationer i VFS styres og kontrolleres.
To achieve this interaction between end systems, FTAM incorporates a set of file protocols which control and specify the required operations on the VFS.
FTAM-tjenesterne og FTAM-protokollen definerer forskellige afhængighedsrelationer:
FTAM services and the FTAM protocol define distinct 'master/slave' relationships:
Enhver forbindelse mellem to FTAM-brugere bliver etableret på initiativ af én bruger (der arbejder ved det aktive system, initiator), som har et bestemt mål, han søger at opfylde.
Each association between two FTAM users is started by one file service user, the initiator, who has some established aim to achieve.
Det slutsystem, der er tilknyttet fillageret (passivt system, responder) gør ikke andet end at reagere på dette initiativ.
The end system associated with the filestore, the responder, merely reacts to this initiative in a passive role.
Dette gælder også i de tilfælde, hvor en fil overføres fra et fillager til et andet.
Triis is true even when a file is being transferred from one filestore to another.
Når der overføres filer, er det ene slutsystem filafsender, det andet -modtager.
When transferring files, one end system is the sender of the files and the other the receiver.
På ethvert tidspunkt har datastrømmen en bestemt retning.
At any given time, there is a specific direction of data flow.
Interaktion defineret i FTAM-stai ildarden:
Interaction defined by the FTAM standard
Lokale afbildningsfunktioner:
Local mapping function
Fil- og dataadministration er implementeret på mange forskellige måder i eksisterende systemer.
Files and data management have a wide range of different implementations in existing systems.
For at kunne definere en protokol for filoverførsel og -tilgang i et åbent heterogent miljø er der behov for et mere ensartet syn på filbegrebet, dvs. for en generel filmodel (eventuelt et lille antal forskellige, men standardiserede modeller). Denne generelle model kaldes VFS (Virtual Filestore).
In order to define a file transfer and access protocol for an open, heterogeneous environment, there is a need for a unified view of the concept of files, for a general file model (or a small set of different but standardized file models).
I VFS-modellen er filstrukturen defineret ved hjælp en hierarkisk filmodel. Den beskriver filer som en hierarkisk struktur, dvs. som en træstruktur med knuder (forgreningspunkter).
In the virtual filestore model, file structure is defined using a hierarchical file model.
Hver knude indeholder en vis mængde strukturel information, f.eks. et navn og eventuelt en bestemt mængde brugerdata, der kaldes en dataenhed (DU, Data Unit) (jvf. figur 3.1.2/5).
Each node contains some structural information, e.g. a name and optionally a unit of user data, called a data unit or DU (see Figure 3.1.2/5).
En knude og alle dens underliggende knuder, kaldes en FADU (File Access Data Unit).
A node, together with all its subordinate nodes, is called a file access data unit (FADU).
Det samlede FADU-deltræ (dvs. FADU-roden og alle underliggende knuder udgør de enheder, gennem hvilke der opnås tilgang til en virtuel fil. De er adressérbare for overførsel og tilgang.
The full subtree of a FADU and the root node of a FADU are the units in terms of which access to a virtual file is achieved.
Det aktive FTAM-system ser altid det ikke-lokale systems fillager som et virtuelt fillager.
The view provided to the FTAM initiator of the filestore of a remote system is always that of its virtual filestore.
Forholdet mellem det virtuelle fillager og systemets egentlige fillager ligger uden for FTAM-standarden (figur 3.1.2/6).
The embedding of the virtual filestore into a system's real filestore with the corresponding mapping function is outside the scope of the FTAM standard (Figure 3.1.2/6).
Det er overladt til implementøren at afgøre, hvorledes afbildning mellem virtuelt og egentligt lager skal finde sted (se også II.2.3, AFBILDNING AF EGENTLIGE FILER).
This mapping is left to the choice of the implementor (see also II.2.3, 'Mapping of real files').
OSI omgivelser for FTAM
< r environment for FTAM scope of OSI
Figur 3.1.2./6: Virtuelt fillager og egentligt fillager
Figure 3.1.2/6: Virtual filestore and real filestore
Til filerne i det virtuelle fillager hører en liste over filattributter, der beskriver den enkelte fils karakteristika. Disse beskrivende filattributter indeles i tre hovedgrupper.
Associated with files in the virtual filestore is a list of file attributes describing the characteristics of that file.
FTAM-kerneattributterne fastsættes på det tidspunkt, hvor filen oprettes.
The FTAM kernel attributes are set when a file is created.
- permitted actions: operationer, der kan udføres på filen (læse, indsætte, erstatte, udvide, slette dele af filindhold, læse attributter, ændre attributter, slette fil), og oplysninger om, på hvilken måde der er tilgang til en struktureret fil (dvs. sekventiel eller direkte tilgang) - kan ikke ændres;
(ii) permitted actions: the actions which can be performed on the file (read, insert, replace, extend, erase, read attributes, change attributes, delete file) and the method by which structured files may be accessed (i.e. sequentially or by random access) - non-modifiable;
I FTAM er det et krav, at alle aktive {Initiators) systemer er i stand til at bruge disse attributter (f.eks. når en fil oprettes eller udvælges med henblik på yderligere behandling), og at alle passive (Responders) systemer reagerer på en relevant måde.
FTAM requires that all initiators be capable of using these attributes (e.g. when creating or selecting a file for further processing), and that all responders react in the appropriate manner as requested.
Visse af disse attributter ændres automatisk, når der læses i filen, eller når den undergår en eller anden forandring, men de kan ikke umiddelbart ændres.
Some of these attributes are modified automatically when the file is read or modified but cannot be modified directly:
3.1.2 FTAM adgang til (f.eks. magnetbånd eller udskiftelig disk).
When the attribute is set to 'deferred availability', it is assumed that the file is stored on a dismountable device which is currently dismounted (e.g. a tape drive or removable fixed disk).
Anmoder det aktive system (Initiator) om, at attributtet ændres til immediate availability, er det en besked til det passive system (Responder) om, at filen skal kopieres over til et umiddelbart tilgængeligt medium, eller at det medium, filen er lagret på, skal gøres tilgængeligt.
If the initiator requests that the attribute be changed to 'immediate availability' it may indicate to the responder that the file should be copied to an immediately available device or that the device on which the file is stored should be mounted.
- filesize: ændres, når filen lukkes efter at være blevet ændret eller udvidet.
However, the interpretation of this attribute is not defined in the standard; filesize: altered when the file is closed after the file contents have been modified or extended.
Værdien af denne attribut viser den lagerkapacitet, der er udnyttet i det egentlige fillager. Dette betyder, at en og samme fil kan have forskellige filesize— værdier, alt efter hvordan det system, den er lagret i, repræsenterer de pågældende datatyper.
The value of this attribute reflects the storage capacity used in the real filestore and therefore the same file may have a different filesize when stored on systems which use different representations of the data types involved.
- future filesize: filens maksimale størrelse efter ændring eller udvidelse.
Some filestores allocate space for a file in multiples of a basic unit (e.g. blocks), in which case the attribute will reflect this value which will not be the true filesize; future filesize: the size to which the file may grow as a result of modification or extension.
Det aktive system (Initiator) kan ændre værdien ved hjælp af en change attribute--operation.
The initiator may change this parameter using the change attributes action.
Når filen når op på en størrelse svarende til værdien vi future filesize, kan det passive system (Responder) enten forhøje attributtets værdi (med eller uden advarsel til det aktive system) eller undlade at forhøje værdien, men komme med et fejlmeddelelse.
When the file reaches a size equal to the value of the future filesize attribute, the responder may either increase the future filesize with or without warning to the initiator, or not increase the future filesize and indicate an error.
Support af de forskellige lagerattributter er ikke obligatorisk ifølge FTAM-standar-den.
The support of the group of storage attributes is optional in the FTAM standard.
Såfremt det aktive system (Initiator) understøtter attributterne, skal det være i stand til at fastsætte værdierne for storage account, file availability og future filesize.
If supported by an initiator, then that initiator is required to be capable of setting the values of the attributes storage account, file availability, future filesize.
De øvrige attributter administreres udelukkende af det passive system (Responder). der).
The remaining attributes are maintained by the responder only.
Det gælder f.eks., når attributter, der er defineret i FTAM, ikke findes i det egentlige fillager, og der derfor ikke kan implementeres nogen afbilding mellem det egentlige og det virtuelle fillager for disse attributter.
This applies, for instance, when some attributes defined in FTAM are not present in the real filestore and therefore no mapping between the real and virtual filestore can be implemented for these attributes.
For det andet kan passive systemer (Responders) understøtte et attribut fuldt ud, hvilket betyder at en meningsfuld værdi, der er i overensstemmelse med definitionerne i FTAM, skal returneres til det aktive system (Initiator).
Alternatively a responder may fully support an attribute in which case a meaningful value as defined in FTAM must be returned to the Initiator.
III SUPPLERENDE TEKNISKE OPLYSNINGER ner (læse, indsætte, erstatte, udvide) eller spærreanordninger, der afgør, i hvilken grad der skal tillades adgang til en fil for flere brugere samtidig. Disse betingelser kan eventuelt ændres ved en change attribute-opeiation;
Examples are passwords associated with individual access actions (e.g. read, insert, replace, extend) or concurrency locks which determine the method allowed for concurrent access to a file by different users.
- legal qualifications: oplysninger om filens retlige status og retlige betingelser for dens anvendelse.
Legal qualifications: information about the legal status of the file and its use.
Der er ikke nogen standardiseret fortolkning af dette attribut.
There is no established interpretation of this attribute.
Såfremt de understøttes, er det et krav, at aktive systemer understøtter dem begge. Passive systemer (Responders) kan derimod eventuelt nøjes med delvis at understøtte disse attributter (således som det er forklaret for lagerattributter ovenfor).
If supported, then it is required that initiators support both attributes.
Filer kan beskrives ved hjælp af såkaldte constraint sets, der fastlægger en nyttig opdeling af filmodellens generelle hierarkiske struktur.
Files can be further described by constraint sets, which define useful subsets of the general hierarchical structure of the file model.
Blandt de definerede constraint sets er:
Among the constraint sets which have been defined are:
En enkelt DU uden navn og uden underordnede knuder.
One-level hierarchy of file data.
En rodknude uden DU og en række unavngivne yderste led (blade i træstrukturen) hver med en DU.
Two-level hierarchy of file data. A root node without a data unit and a series of unnamed leaf nodes each with a data unit.
En rodknude uden DU og en række navngivne yderste led hver med en DU.
A root node without a data unit and a series of named leaf nodes, each with a data unit.
En dokumenttype registreres og identificeres ved hjælp af et globalt entydigt objektsnavn, der således kan bruges som filattribut. Visse dokumenttyper er defineret i FTAM-standarden.
A document type is registered and identified by a world wide unique object identifier, which can thus be used as a file attribute.
Andre kan specificeres og registreres til opfyldelse af specifikke brugerbehov. Blandt de eksisterende dokumenttyper er:
Others may be specified and registered according to specific user requirements.
- FTAM-1: Ustruktureret fil indeholdende tekstdata.
FTAM-1: Unstructured file of text data.
Det kan med en parameter angives, hvilket tegnområde der findes i filen (jvf. III.4, Dokumenttype FTAM-1, for yderligere oplysninger).
A parameter can be used to indicate the range of characters present in the file (for more details see III.4, document type FTAM-1).
Tegn vil altid blive kodeoversat fra
Characters will always be transcoded from the local representation of the sending system to the local representation of the receiving system.
- FTAM-3: Ustruktureret fil indeholdende binære data. Behandles som en række af bytes, der overføres som en transparent datastrøm, uden at værdierne har mening knyttet til sig.
FTAM-3: Unstructured file of binary data, i.e. it is treated as a series of octets which are transmitted as a transparent data stream with no meaning attached to the values.
- FTAM-4: Sekventiel flad fil indeholdende binære data.
FTAM-4: Sequential flat file of binary data.
- NBS-9: Fil indeholdende filkatalog.
NBS-9: File directory file.
Kan anvendes som filkatalog i det passive systems (Responders) virtuelle fillager.
It may be used as a file directory in a responder's virtual filestore.
Indeholder filnavne og -attributter og kan læses af et aktivt system.
It lists file names and attributes and can be read by an initiator system.
Vedligeholdes af det passive system (Responder).
This file is maintained by the responder system.
Filens egenskaber afhænger af den konkrete implementering.
Its characteristics are implementation-specific.
Den muliggør lagring og overførsel af meget lange records (i størrelsesordenen en eller flere megabyte), f.eks. inden for billedbehandling. Dette gøres ved at opdele records i mindre dele og forbinde disse dele med hinanden. Der kan eventuelt anvendes en komprimeringsmetode, således at den datamængde, der overføres, kan for mindskes.
It allows storage and transfer of very long records (megabyte order of magnitude), e.g. in the area of image processing, by using the concept of breaking such records into smaller elements and linking these elements together.
Som allerede nævnt er en FADU og de tilknyttede DU'er de mindste dele i en virtuel fil, for hvilke tilgang er defineret.
As already mentioned, a FADU and the associated data units are the minimal portions of a virtual file in terms of which access is defined.
Den konkrete overførsel af DU'er - der godt kan være temmelig lange - kan ske gennem en yderligere opdeling i mindre stykker, benævnt dataelementer.
The actual transfer of data units - which might be long pieces of data - can be accomplished by subdivision into smaller pieces, called data elements.
En DU kan altså sendes i mindre stykker eller dataelementer, som modtageren kan sammenstykke til den oprindelige DU.
A sender may send a data unit in pieces, split up into several data elements, and the receiver can reassemble these data elements to build up the data unit.
Den måde, hvorpå en DU er opdelt i dataelementer, kan være en kilde til yderligere information for modtageren - f.eks. kan hvert dataelement repræsentere ét felt i en record, en tekstlinie osv. Dette er illustreret i følgende eksempler på afbildning mellem egentlige og virtuelle filstrukturer.
The way the data unit is split into data elements may provide the receiver with additional information, e.g. each data element may represent one field of a record, one line of text, etc. This is illustrated in the following examples of mapping between real and virtual file structures.
Underopdelingen i dataelementer i forbindelse med overførslen er tilfældig og indeholder ikke supplerende strukturel information.
The subdivision into data elements for transfer is arbitrary and carries no additional structural information.
Tekstfilens liniestruktur overføres ved hjælp af styrekoderne vognretur (CR) og linieskift (LF).
The line structure of the text file is transmitted using the control characters carriage return (CR) and line feed (LF).
Den kan ligeledes overføres som en FTAM-2-fil, idet hver DU da indeholder netop én record (i dette tilfælde er der enten ikke tale om yderligere opdeling i dataelementer, eller der
It may also be transferred as an FTAM-2 file, each data unit carrying exactly one record (in this case the further subdivision into data elements is either not applied or is only applied along with a representation of additional structural information).
III SUPPLERENDE TEKNISKE OPLYSNINGER findes parallelt med opdelingen en repræsentation af supplerende strukturel information). mation).
SUPPLEMENTARY TECHNICAL INFORMATION
- Transfer Service Class - Tjenesteklassen for dataoverførsel muliggør flytning af filer eller dele af filer fra ét system til et andet.
The transfer service class allows the movement of files or parts of files between systems.
Der er især tale om enkle opgaver med minimal protokoludnyttelse før og efter dataoverførslen, dvs. at der kun kan foretages enkeltstående operationer med et minimalt antal interaktioner. aktioner.
Emphasis is placed on simple tasks with a minimum of protocol overhead before and after the data transfer, by allowing only single operations with a minimum number of interactions.
- Management Service Class - Tjenesteklassen for håndtering gør det muligt for brugeren at udføre følgende operationer på det virtuelle fillager: oprettelse og sletning af filer, læsning af filattributter og - eventuelt - ændring af filattributter.
The management service class allows the user control of the VFS as follows: creation and deletion of files, reading of file attributes and-optionally-modification of file attributes.
- Read: Åbning og lukning af filer, læsning af hele filer eller udvalgte FADU'er.
Read: Opening and closing files, reading complete files or specified FAD Us.
Åbning og lukning af filer, skrivning af hele filer eller tilføjelse, erstatning eller udvidelse af udvalgte FADU'er.
Opening and closing files, writing complete files or inserting, replacing or extending specified FADUs.
- Limited File Management: Oprettelse og sletning af filer, læsning af filattributter.
Limited file management: Creating and deleting files, reading file attributes.
- Enhanced File Management: Gennemførsel af ændringer i filattributter.
Enhanced file management: Changing attributes of a file.
- FADU Locking: Fastlæggelse af tilgangsblokering (for at styre samtidig tilgang til en fils FADU'er).
FADU locking: Specifying access locks (concurrency locks) to FADUs of a file.
Gør det muligt for det aktive system at reetablere FTAM-forbindelser, der fejlagtigt er afbrudt.
Allows the initiator to recreate FTAM associations which have been interrupted by a failure.
Såfremt en fil er åben og under behandling, vil reetableringen finde sted automatisk ved hjælp af checkpoints og dockets, sidstnævnte registrerer alle oplysninger om FTAM-forbindelsen, som er nødvendige for reetableringen.
If a file has been opened and processed, the recovery will be carried out automatically thanks to the use of checkpoints and dockets, the latter preserving all necessary information of the FTAM association in order to recover after the failure.
I princippet kan ISO 8571 understøtte endog meget avancerede filbehandlingsteknikker.
ISO 8571 specifies services and protocols for the transfer of complete or partial files, with optional error recovery, but does not specify the application which 'drives' the transfer.
Med det formål at gøre de forskellige produkter hurtigt tilgængelige dækker omtalen af FTAM type 1 i nærværende håndbog imidlertid kun overførsel af hele filer.
In principle, ISO 8571 can support very sophisticated filehandling techniques but, in order to encourage early product availability, this handbook's FTAM Type 1 only supports the transfer of files in their entirety.
Det er usandsynligt, at de første FTAM-implementeringer vil indeholde alle de funktioner, der tilbydes i mange eksisterende leverandørspecifikke filservere, og det vil i reglen være at anbefale, at der på kort og mellemlang sigt vælges leverandør specifikke løsninger på lokal filbehandling (f.eks. mellem PC'er på det samme lokalnet).
It is unlikely that early FTAM implementations will possess the range of functions which is provided by many existing proprietary 'file servers' and it will usually be advisable to consider proprietary solutions for local file handling (e.g. between PCs on the same LAN) in the short to medium term.
Imidlertid er der for sådanne systemer også ofte behov for filbehandling i forbindelse med kommunikation med systemer på andre net eller mellem systemer på samme net, men af forskelligt fabrikat.
However, it is probable that such devices will also need a filehandling capability for communication with systems on other networks or between different vendors' devices connected to the same network.
Der. bør i anskaffelsesfasen tages hensyn til sådanne behov.
An implementation should be considered which meets such requirements.
Hvorvidt den implementerede løsning knyttes til enkeltstående arbejdsstationer eller har form af en ressource, alle nettets brugere kan trække på (placeret på f.eks. en f i W kommunikations ser v er ) afgøres af den ordregivende myndighed.
Whether this implementation resides on individual workstations or as a resource available to all users on the network (e.g. on a file/communications server) is left to the preference of the procurer.
Uanset om de øjeblikkelige filbehandlingsbehov kan tilfredsstilles fuldt ud gennem en leverandørspecifik løsning, bør den ordregivende myndighed stille krav om, at systemet har visse FTAM-funktioner, således at fremtidige indkøb ikke begrænses til samme leverandørspecifikke løsning.
Even if the initial filehandling requirement can be entirely satisfied by proprietary solutions, the procurer needs to specify that some FTAM capabilities reside on the system so as to not restrict future procurements to adopting the same proprietary solution.
Dette er illustreret i nedenstående scenarier.
This is illustrated in the scenarios which follow.
Et lokalnet i et bygningskompleks, fungerer med udstyr af fabrikat A (figur 3.1.2/7).
A building-wide LAN supports equipment from Vendor A (Figure 3.1.2/7).
AO fungerer som filserver for arbejdsstationerne Al, A2 osv. De fleste af de fil behandlingsbehov, der opstår i forbindelse med arbejdet med A-arbejdsstationerne, kan opfyldes gennem det leverandørspecifikke filsystem af fabrikat A, men der kan i fremtiden muligvis blive behov for tilgang til ikke-lokale fillagre (f.eks. CO) gen nem et globalt net (WAN, Wide Area Network). En løsning er vist i figur 3.1.2/7.
A file server AO can be called up for filehandling routines by workstations Al, A2, etc.
For at opfylde dette behov implementerer leverandør A FTAM på filserveren.
To meet the requirement, Vendor A implements FTAM on the file server.
FTAM kan herefter anvendes som filbehandlingsrutine af arbejdsstationerne Al, A2 osv. på samme måde som enhver anden netanvendelse.
FTAM can then be called up as a filehandling routine by workstations Al, A2, etc., just like any other networked application.
En A-arbejdsstation kan herved få tilgang til det ikke-lokale fillager CO via et globalt net (WAN).
In this way, an A-type workstation can access remote filestore CO via the WAN to retrieve files from it.
Det samme lokalnet fungerer ligeledes med udstyr af fabrikat B (figur 3.1.2/8).
The same building-wide LAN also supports equipment from Vendor B (Figure 3.1.2/8).
For visse af B-arbejdsstationernes vedkommende er der behov for adgang til A-filserveren AO og til det ikke-lokale fillager CO.
There is a requirement for certain of the B-type workstations (e.g. Bl) to have access to the A-type file server AO and also to the remote filestore CO.
Lokalt Fillager fabrikat B
Local filestore (Vendor B)