Hi Team, More findings on the above are as follows :-
*I have tested the above scenario with FreeRDP version 2.0.0 rc4 [ on ubuntu ] and it is working fine.* *I have tested for RDP 8 and RDP 10.* Thanks and Regards, Amarjeet Singh On Fri, Feb 8, 2019 at 9:28 AM Amarjeet Singh <[email protected]> wrote: > Hi Team, > > If target system is not windows then SharedAccess=0 which imeans there is > no need to implement it. > > #ifndef WIN32 >> file->SharedAccess = 0; >> #endif >> file->file_handle = CreateFileW(file->fullpath, >> file->DesiredAccess, >> file->SharedAccess, NULL, >> CreateDisposition, >> file->FileAttributes, >> NULL); > > > Any thoughts on the above ? > If that is not the case then what is it that I am missing? > > Thanks > > On Thu, Feb 7, 2019 at 11:13 PM Amarjeet Singh <[email protected]> > wrote: > >> Hi Team, >> >> Findings on the below issue is as follows :- >> >> I went ahead read about the shared access from *File System Behavior in >> the Microsoft Windows Environment* DOCS >> in which there is description of OPLOCK SEMANTICS. >> >> Oplock Semantics >>> 2.1 Overview >>> >>>> Opportunistic locks, or oplocks, provide a mechanism that allows file >>>> server clients (such as those utilizing the SMB and SMB2 protocols) to >>>> dynamically alter buffering strategy for a given file or stream in a >>>> consistent manner to increase performance and to reduce network use. To >>>> increase the network performance for remote file operations, a client can >>>> locally buffer file data, which reduces or eliminates the need to send and >>>> receive network packets. For example, a client may not have to write >>>> information into a file on a remote server if the client knows that no >>>> other process is accessing the data. Likewise, the client may buffer >>>> read-ahead data from the remote file if the client knows that no other >>>> process is writing data to the remote file. Applications and drivers can >>>> also use oplocks to transparently access files without affecting other >>>> applications that might need to use those files. >>>> Oplocks are granted on stream handles, meaning that the operations >>>> apply to the given open stream of a file and, in general, operations on one >>>> stream do not affect oplocks on a different stream. There are exceptions to >>>> this, which are explicitly listed below. >>>> There are currently eight different types of oplocks: >>>> >>>>> 1. A Level 2 (or shared) oplock indicates that there are multiple >>>>> readers of a stream and no writers. This supports client read caching. >>>>> 2. A Level 1 (or exclusive) oplock allows a client to open a stream >>>>> for exclusive access and allows the client to perform arbitrary buffering. >>>>> This supports client read caching and write caching. >>>>> 3. A Batch oplock (also exclusive) allows a client to keep a stream >>>>> open on the server even though the local accessor on the client machine >>>>> has >>>>> closed the stream. This supports scenarios where the client needs to >>>>> repeatedly open and close the same file, such as during batch script >>>>> execution. This supports client read caching, write caching, and handle >>>>> caching. >>>>> 4. A Filter oplock (also exclusive) allows applications and file >>>>> system filters (including minifilters), which open and read stream data, a >>>>> way to “back out” when other applications, clients, or both try to access >>>>> the same stream. This supports client read caching and write caching. >>>>> 5. A Read (R) oplock (shared) indicates that there are multiple >>>>> readers of a stream and no writers. This supports client read caching. >>>>> 6. A Read-Handle (RH) oplock (shared) indicates that there are >>>>> multiple readers of a stream, no writers, and that a client can keep a >>>>> stream open on the server even though the local accessor on the client >>>>> machine has closed the stream. This supports client read caching and >>>>> handle >>>>> caching. >>>>> 7. A Read-Write (RW) oplock (exclusive) allows a client to open a >>>>> stream for exclusive access and allows the client to perform arbitrary >>>>> buffering. This supports client read caching and write caching. >>>>> 8. A Read-Write-Handle (RWH) oplock (exclusive) allows a client to >>>>> keep a stream open on the server even though the local accessor on the >>>>> client machine has closed the stream. This supports client read caching, >>>>> write caching, and handle caching. >>>>> Level 1, Level 2, and Batch oplocks were implemented in Windows NT >>>>> 3.1. The Filter oplock was added in Windows 2000. R, RH, RW, and RWH >>>>> oplocks have been added in Windows 7. >>>> >>>> >> Please find the attached document of the above. >> >> Guacamole VIRTUAL FILE DRIVE REDIRECTION hasn't implented it whereas >> FreeRDP 2.0.0 has implemented it. >> >> *Guacamole Code :* >> >>> void guac_rdpdr_fs_process_create(guac_rdpdr_device* device, >>> wStream* input_stream, int completion_id) { >>> wStream* output_stream; >>> int file_id; >>> int desired_access, file_attributes, sharedAccess; >>> int create_disposition, create_options, path_length; >>> char path[GUAC_RDP_FS_MAX_PATH]; >>> /* Read "create" information */ >>> Stream_Read_UINT32(input_stream); /* Desired Access */ >>> Stream_Seek_UINT64(input_stream); /* allocation size */ >>> Stream_Read_UINT32(input_stream, file_attributes); >>> Stream_Read_UINT32(input_stream, sharedAccess); /* shared access */ >>> Stream_Read_UINT32(input_stream, create_disposition); >>> Stream_Read_UINT32(input_stream, create_options); >>> Stream_Read_UINT32(input_stream, path_length); >>> } >> >> *FreeRDP 2.0.0 Code while creating or opening a file:-* >> >>> >>> if (dwShareMode & FILE_SHARE_READ) >>> lock.l_type = F_RDLCK; >>> if (dwShareMode & FILE_SHARE_WRITE) >>> lock.l_type = F_RDLCK; >>> #else >>> if (dwShareMode & FILE_SHARE_READ) >>> lock = LOCK_SH; >>> if (dwShareMode & FILE_SHARE_WRITE) >>> lock = LOCK_EX; >>> #endif >>> if (dwShareMode & (FILE_SHARE_READ | FILE_SHARE_WRITE)) >>> { >>> #ifdef __sun >>> if (fcntl(fileno(pFile->fp), F_SETLKW, &lock) == -1) >>> #else >>> if (flock(fileno(pFile->fp), lock) < 0) >>> #endif >>> { >>> #ifdef __sun >>> WLog_ERR(TAG, "F_SETLKW failed with %s [0x%08X]", >>> #else >>> WLog_ERR(TAG, "flock failed with %s [0x%08X]", >>> #endif >>> strerror(errno), errno); >>> SetLastError(map_posix_err(errno)); >>> FileCloseHandle(pFile); >>> return INVALID_HANDLE_VALUE; >>> } >> >> >> I have tried mstsc and redirected the shared drive and tried to save the >> file in it and it works whereas it fails in Guacamole Server Shared Drive [ >> For Info : I tried everywhere including download and outside the download >> folder as well.] >> >> >> I tried another solution also which provides RDP on browser and it works >> fine. >> >> I will try with *FreeRDP 2.0.0* and *FreeRDP 1.0.2* client on windows >> as well and update with you the same. >> >> Thanks, >> Amarjeet Singh >> >> >> >> On Wed, Feb 6, 2019 at 1:43 PM Amarjeet Singh <[email protected]> >> wrote: >> >>> If you are attempting to save the file directly into the "Download" >>>> folder, >>>> it is likely that the application is repeatedly closing and reopening >>>> the >>>> file over the course of saving things. As Guacamole will automatically >>>> delete the file and begin downloading once the file is closed, an >>>> application which behaves in this way will not work correctly. You will >>>> need to save the file elsewhere and then move it to the "Download" >>>> folder. >>> >>> >>> Thanks Mike for helping me out with this. >>> >>> I have tried to save the file instead of downloading in the Download >>> folder and got the same error. >>> >>> Thanks, >>> Amarjeet Singh >>> >>> >>> >>> On Wed, Feb 6, 2019 at 12:11 AM Mike Jumper <[email protected]> wrote: >>> >>>> On Tue, Feb 5, 2019 at 9:50 AM Amarjeet Singh <[email protected]> >>>> wrote: >>>> >>>> > ... >>>> > While trying to download pdf and rtf files in the local operating >>>> system [ >>>> > Windows 10 ], I am getting the below error :- >>>> > >>>> > Report Builder *REP-0081* error during file i/o operation scaba 16 >>>> > >>>> > >>>> > ... It is only writing *10 bytes* and corrupted pdf file is >>>> downloaded. >>>> > >>>> >>>> If you are attempting to save the file directly into the "Download" >>>> folder, >>>> it is likely that the application is repeatedly closing and reopening >>>> the >>>> file over the course of saving things. As Guacamole will automatically >>>> delete the file and begin downloading once the file is closed, an >>>> application which behaves in this way will not work correctly. You will >>>> need to save the file elsewhere and then move it to the "Download" >>>> folder. >>>> >>>> - Mike >>>> >>>
