This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server


On Aug 24 09:13, Heinz Werner Kramski wrote:
> While Cygwin 1.5 played well with our legacy file server (Tru64
> Advanced Server V5.1B-4 ECO2), 1.7 does not.
> 
> Although I seem to have sufficient write permissions (and actually
> can write to files), renaming (mv-ing) files fails with 1.7.1,
> 1.7.5-1 and 1.7.6-1 (others not tested) like this:
> [...]
> With 1.7.5, it was at least possible to copy files successfully.
> After upgrading to 1.7.6-1, cp now also fails strangely:
>       $ cp somefile copyfile
>       cp: skipping file `somefile', as it was replaced while being copied

Can you please try the latest Cygwin developer snapshot at
http://cygwin.com/snapshots/, so we know this isn't fixed by the
latest bugfixes.

> Mounting with the "noacl" option doesn't help:

There's also a new mount option "ihash" since 1.7.6.  It might help
with the "cp" issue above, but that probably doesn't help with the
"mv" issue.

>       $ mv somefile newfile2
>       mv: cannot move `somefile' to `newfile2': Permission denied
> [...]
>       $ /usr/lib/csih/getVolInfo //dlanserv/KRAMSKI$/
>       Device Type        : 7
>       Characteristics    : 10
>       Volume Name        : <DLANSERV     >
>       Serial Number      : 4294967292
>       Max Filenamelength : 255
>       Filesystemname     : <NTFS>
>       Flags              : 8
>         FILE_CASE_SENSITIVE_SEARCH  : FALSE
>         FILE_CASE_PRESERVED_NAMES   : FALSE
>         FILE_UNICODE_ON_DISK        : FALSE
>         FILE_PERSISTENT_ACLS        : TRUE
>         FILE_FILE_COMPRESSION       : FALSE
>         FILE_VOLUME_QUOTAS          : FALSE
>         FILE_SUPPORTS_SPARSE_FILES  : FALSE
>         FILE_SUPPORTS_REPARSE_POINTS: FALSE
>         FILE_SUPPORTS_REMOTE_STORAGE: FALSE
>         FILE_VOLUME_IS_COMPRESSED   : FALSE
>         FILE_SUPPORTS_OBJECT_IDS    : FALSE
>         FILE_SUPPORTS_ENCRYPTION    : FALSE
>         FILE_NAMED_STREAMS          : FALSE
>         FILE_READ_ONLY_VOLUME       : FALSE
>         FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>         FILE_SUPPORTS_TRANSACTIONS  : FALSE

These flags result in Cygwin treating the drive as a filesystem
just faking to be NTFS.  It's subsumed under the "cifs" type.
For these filesystems, just two assumptions are made:

- Don't use the FileIdBothDirectoryInformation info class in
  readdir().

- The filesystem only handles filenames following DOS rules.

However, the filesystem claims to have persistent ACLs, so the
assumption is that it has ACLs, and that it returns valid inode numbers.
Both assumptions can be overridden by mount options (noacl,ihash).

That probably still doesn't explain the "Permission denied" in case
of mv.  Would you mind to create an strace under the latest Cygwin
developer snapshot, like this:

  $ strace -o mv.trace mv somefile newfile

and send us the mv.trace file?  This might give a clue where the
problem occurs.  Maybe we can find a workaround.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]